Bonnema, Gerrit Maarten

Rajabali Nejad, Mohammadreza

English

University of Twente Research Information

Risk, Reliability and Safety: Innovating Theory and Practice – Walls, Revie & Bedford (Eds)© 2017 Taylor & Francis Group, London, ISBN 978-1-138-02997-2AMDesigner: An architecture modeling tool for the use inmulti-disciplinary design projectsM. Rajabalinejad & G.M. BonnemaLaboratory of Design, Production and Management, Faculty of Engineering Technology,University of Twente, Enschede, The NetherlandsABSTRACT: This study resembles the use of AMDesigner (AMD) in several multi-stakeholder projects toexplore the commonly used elements of this framework. For this purpose, AMD was used in several projects(technical and none-technical). The users had no prior experience on the use of architecture modelling tools. Tostimulate the usage, a 30 minutes description of the tool was offered. This paper reviews the commonly practicedframeworks for the architecture modeling, briefly reviews the elements of AMD, describes the set-up for theexperiments and draws conclusions form its implementations.1 INTRODUCTIONThe design and engineering of complex systemsdemand effective communication among membersof the design team or the people who have inter-est in the product, system or services: the so-calledsystem stakeholders. Good communication preservesmany resources and positively influence the consis-tency of available information and so the integrationphase (G. M. Bonnema, 2011; Woestenenk, 2014).This demands for an architecture model which can beeasily communicated with the stakeholders. Further-more, an architecture model provides the basics forcapturing the design information to enable its reuse.These aspects have clear influence on the elements ofperformance triangle: cost, time-to-market and qual-ity (Rajabalinejad et al., 2015; Theisens, 2014). Herewe present the commonly practiced languages for thesystem modelling.Unified Modelling Language (UML) was devel-oped as a general-purpose modeling language devel-oped for software engineers extended for the use ofsystem architects with tools for design and implemen-tation of software-based systems, modelling businessor similar processes (ISO/IEC, 2012).To engineer complex products or systems, the Inter-national Community of Systems Engineers (INCOSE)considers the Model Based Systems Engineering asan essential enabler for systems engineers (INCOSE,2015). This community uses the OMG SysML lan-guage for describing the system. SysML reuses a sub-set of UML and provides extensions for covering therequirements for system engineers (OMG, 2015). TheArchitecture Analysis and Design Language (AADL)was developed by SAE to design and analyze thesoftware and hardware architecture and performance-critical real-time systems. It focuses on special needsof these systems and enables analysis of their proper-ties. The Zachman framework provides ontology fordescribing the enterprise (Zachman, 1987). Thus itprovides basis for the system architecture.The Depart-ment of Defense Architecture Framework (DoDAF) isa comprehensive framework and conceptual model forarchitectural description within DoD. It provides struc-ture for organizing architecture, assumptions, and ter-minology about the operational solutions (DoD, 2015).The Open Group Architecture Framework (TOGAF)is a supporting tool for developing enterprise archi-tecture (GROUP, 2011). Object-Process Methodology(OPM) is a compact conceptual approach capableof establishing basis for system architects, designersand system developers (ISO, 2013). The British Min-istry of Defense Architecture Framework (MODAF)to support defense planning and change management(see modaf.com). The Nato Architecture Framework(NAF) is developed for developing Enterprise Archi-tectures and creating a model of current and futurestate of an enterprise (see nafdocs.org). The Busi-ness Process Model and Notation (BPMN) providesan understandable notation easily understandable bybusiness users for modeling and analysis of businessprocesses (OMG, 2011).The Federal EnterpriseArchi-tecture Framework (FEAF) supports planning anddecision-making through documentation and informa-tion that provides an abstract view at different levelsof scope and detail (www.egov.gov, 2013).This research builds on the tested hypothesis thatthe use of a common language that describes the sys-tem architecture and information flow improves thecommunication in the course of design (G. MaartenBonnema, 2014). It adapts the theoretical architecturemodel (AM) (see (Woestenenk, 2014)) and presentsthe benchmarks for developing a software tool on itsbasis. Some specific aspects of this tool have been2391highlighted here. Furthermore, the observations on theuse of this tool have been summarized through differ-ent multidisciplinary projects. Conclusions have beendrawn and considerations have been highlighted for thefuture development of this tool. Next section provideson the specifics of the architecture model developedthrough the IOP project.2 THE HIGHLIGHTSAs a part of the national program for innovation(IOP), the research aims to develop a prototype toolto automate the generation of control software formechatronic machines. To achieve this, earlier studiesconcluded the importance of the architecture mod-elling. Among others, K. Woestenenk and A. Cabareraconcluded through their PhD dissertations (Cabrera,2011; Woestenenk, 2014) the essential influence ofarchitecture modelling for developing mechatronicmachines. To represent an architecture model, therehas been a need for a software tool that is user-friendly, robust and able to support companies for theirproject in real-time. The earlier mentioned PhD thesesprovided a solid framework for such an architecturemodeler.University of Twente (UT) and Embedded Sys-tem Institute (ESI) conducted research projects aboutarchitecture modelling tools. UT kept its focus aroundcreating a pragmatic tool for high-tech companies inorder to capture the Architecture Model. This archi-tecture model is used for improving communicationamong the design team-members resulting in consis-tency of views and data. This accelerates the inte-gration process in the course of developing complexproducts (Woestenenk et al., 2012) given the diversityof stakeholders’ opinions (Rajabalinejad et al., 2014).Furthermore, it facilitates access to the information forfuture use.The results of discussions with industrial partnersand information exchange with software developershighlighted the items below for development of theAMDesigner.• requirements for the tool• capturing specialised design processes• testing the results in real-world projects• document the findings for future development2.1 The user interfaceThe tool has to be robust. That was concluded fromprevious research, explicitly indicated through the pro-posal, and clearly requested by industrial partners. Toserve this need, the AMDesigner was developed underthe Model-View-View-Model (MVVM) design pattern.Developed by Microsoft, this pattern was created fordecoupling the user-interface and none-user-interfacecodes. This pattern enables a layered data structure forbinding the data and user interface. It organizes thecode in such a way that it facilitates future changes/revisions as it structures the code on basis of individualFigure 1. This picture represents the MVVM architectureimplemented in AMDesigner (source: Telerik.com).parts. Adapting this pattern is of primary importancefor this tool as it leads to a robust tool and facilitatessoftware automation.In other words, the MVVM pattern creates a loosesoftware-architecture which is less error-prone thanthe earlier used tightly-coupled software architecture.More information about the MVVM is available onthe Microsoft website. The picture below representsthe concept of loose architecture through differentmodules.3 WORKBENCH3.1 Architecture languageThe PhD research of K. Woestenek (Woestenenk,2014) resulted in defining an architecture languagecomposed of concepts and relations. AMD is built onthis principal definition for concepts while it adaptsthe definition for relations. As these definitions areprerequisite for its use, the definition of concepts andrelationships are included through the text below.3.2 Reference modelIt is common practice to create a complex and multi-disciplinary product based on a reference model. Sucha model contains design information to improve under-standing of the essential design components. TheAMDesigner focuses on the essential system compo-nents required for a functional system. The imple-mented reference model for the AMD includes thefollowing components.• Abstract which represents the abstract view ofthings; therefore, details are not parts of the model.• Entities and Relationships which are both requiredto create a reference model.• Environment helps to show a limited number ofentities and relationships encapsulated by an envi-ronment.2392Figure 2. The allowable relations in the Architecture model adapted from (Woestenenk, 2014).3.3 Concept• Basic Object (BO) is the abstract information unitrequired for all of the concepts.• Architecture Model (AM) is the container of themodel.• View (V) is a stakeholder’s perspective.• Parameter (P) is the most basic information unitwhich defines the information content for otherconcepts.• Function (F) describes what a system does or shoulddo.• Requirement (R) is the border of allowable designspace.• Entity (E) is an structural unit or an object of asystem.• Formula (F) defines how parameter values changeand are related.• Aspect (A) is a quality or characteristic of a systemthat is of interest to a stakeholder.• Domain Entity (DE) is a mono-disciplinary entitydefined in a certain design domain.• Design Task (DT) used to model a design task.• Function Relation (FR) defines the possible inter-face between two functions.• Entity Relation (ER) defines the possible interfacebetween two entities.• Design Task Relation (DTR) defines the possibleinterface between two design tasks.3.4 RelationshipsThe Architecture Model communicates to differentstakeholders/ experts and integrates information toserve the design process primarily from the archi-tecture perspective. This requires a well-defined rela-tionship between those defined concepts (informationunit). There are three sorts of relationships availablethrough this tool• Composition (com) relation which describe a par-ent/child relationship.• Dependency (dep) relation that defines andinput/output or sequence relation.• Association (ass) which relates different concepttypes. This relation is called mapping through(Woestenenk, 2014).Table below presents the permitted relationsbetween different concepts. Further information isFigure 3. A functional view generated by AMDesigner.Figure 4. A structural view generated by AMDesigner.available through pages 201–207 of (Woestenenk,2014). Next section provides some snap-shots on theuse of this tool.4 PRESENTATIONThis section presents functional, structural andrequirement views for an example robot.These are cus-tomized views generated by AMD which are availablefor a system architecture.4.1 Functional viewThrough functional view, the architecture or expertcan create a network of main system functions anddefine the functional interfaces. Figure 3 shows anexample snapshot of the functional relationship. Thefigure is presented in low scale on purpose. Readerswho are interested in further details are advised to see(Woestenenk, 2014).23934.2 Structural viewThrough the structural view, the physical compo-nents and their interfaces are shown. This view showshow different components or electronic elements arelocated or related in order to perform the requiredtasks.4.3 Requirement viewA well designed system must fulfill its requirements.A separate requirement view helps a designer to payattention to the key/derived requirements for the com-ponents or performances. Figure 5 shows an examplerequirement view.4.4 AMDesignerThe software package can be shared for non-commercial and research related uses. To obtain aninstallable version of the AMDesigner, please contactthe authors.Figure 5. A requirement view generated by AMDesigner.Table 1. This table presents the factual observations on the use of AMDesigner.Project Entity Functionalsubject Requirements Entity relationship Function relationship aspect dependency association composition Views parameterBIM o o o o o o o oInstrument o o o o o o o oAutomotive o o o o o o o o o oIntensive o o o o o o o ohumaninteractionEducation o o o o o oscienceNumerical o o o o o o o o o oanalysisControl o o o o o o osystemEducation o o o o o oscienceProcess o o o o oengineering∗Automation o o o o o o o∗The designer had used some domain-specific notations for describing the architecture.5 TEST/OUTCOMEAMDesigner was used in 10 different projects by engi-neers, specialists, or designers (here we call themdesigners) owning at least a Master of Science andoften with several years of experience. The projectswere real-world application of different systems. Thecategory of each project is shown in the first columnof Table 1. The projects range from technical (controlsystems) to none-technical (educational science) andinclude different industries. All the projects includestakeholders from business.To facilitate the use of AMDesigner, a 30 min-utes instruction was provided to the designers over thestructure, elements and usage of AMDesigner. Then,the designers were asked to use AMDesigner for thefollowing purposes:1. Describing the project architecture for communica-tion with the stakeholders and obtaining feedback.2. Modeling (architecting) safety (or another desiredperformance indicator) in the architectural model.The designers had the possibility to deliver a firstdraft for feedback and had to deliver their model.Examination of the delivered models has resulted inTable 1 concluding the following.1. The entity, function and aspect were used in all ofthe models. These seem to be the most commoningredients for developing an architectural model.2. A couple of designers did not include requirementsin their architectural model. These focus on thesolution domain and do not explicitly present therelationship between the needs and the solutions.3. Only two designers used the concept of views. Thisapparently shows that most of the designers hadpreferred one integrated view that includes all theelements and their relationship in one single view.2394This has been observed by other researchers (seee.g. (Rozanski et al., 2012)).4. It seems that the designers who would like to showthe architecture model in one single view have tocomprise for the use of available5. elements. In other words, they have not used all theavailable elements.6. The designers who did use the concept of viewscreated a more elaborated model and used almostall of the elements presented in the table.7. The outcome shows that in order to model a keyperformance indicator through one integrated view(single view), the designers had focused on eitherthe structural or functional view of the system. Wedid not observe a good balance for modeling a KPI(key performance indicator) in one single view thatconnects to both functional and structural elementsof the system.8. In general, the designers find the use of parame-ters less important for developing/communicationof their system architecture.6 CONCLUSIONSHaving clear objectives and the theory of an archi-tecture model, a very practical test was performed tosee the use of AMDesigner in a very wide varietyof applied projects from product-related, numerical,educational, process related, automotive and controlsystems.Though the outcomes, one may conclude that:• the mostly used ingredients of the tool are Entity,function, and aspects.• a very limited use of parameters was observed forpresenting the architectural model.• the use of views can promise a more detailedrepresentation of the architecture model.ACKNOWLEDGEMENTThe authors would like to acknowledge IPCR130065for providing the means for conducting this research.REFERENCESBonnema, G. M. (2011). Insight, Innovation, and the BigPicture in System Design Application of FunKey Archi-tecting. Systems Engineering, 14(3), 223–238. doi:Doi10.1002/Sys.20174Bonnema, G. M. (2014). Communication in Multidisci-plinary Systems Architecting. Procedia CIRP, 21, 27–33.doi: http://dx.doi.org/10.1016/j.procir.2014.03.188Cabrera, A. A. A. (2011). Architecture-Centric Design: Mod-eling and Applications to Control Architecture Genera-tion. (PhD), TUDelft.DoD. (2015). DoD Architecture Framework, V2.0, Volume I(Vol. I: Overview and Concepts).GROUP, O. (2011). Open Group Standard TOGAF Version9.1. U.S.: The Open Group.INCOSE. (2015). A World in Motion, Systems EngineeringVision 2025.ISO. (2013). ISO TC 184/SC 5\WG 1 N 516 ISO/PDPAS19450 ISO TC 184/SC 5/WG 1 Automation systems andintegration – Object-Process Methodology.ISO/IEC. (2012). ISO/IEC 19505-1 First edition 2012-04-15 Information technology – Object Management GroupUnified Modeling Language (OMG UML) – Part 1:Infrastructure.OMG. (2011). Business Process Model and Notation(BPMN).OMG. (2015). OMG Systems Modeling Language (OMGSysMLTM).Rajabalinejad, M., & Bonnema, G. M. (2014). Determinationof stakeholders’ consensus over values of system of sys-tems. Paper presented at the Proceedings of the 9th Inter-national Conference on System of Systems Engineering:The Socio-Technical Perspective, SoSE 2014.Rajabalinejad, M., Bonnema, G. M., & Houten, F. J. A. M.v. (2015). An integral safety approach for design of highrisk products and systems. Paper presented at the Safetyand Reliability of Complex Engineered Systems Zurich,Switzerland.Rozanski, N., & Woods, E. (2012). Software systems archi-tecture: working with stakeholders using viewpoints andperspectives: Addison-Wesley.Theisens, H. C. ( 2014). Climbing the Mountain. Amsterdam:Lean Six Sigma Academy.Woestenenk, K. (2014). Consistency, Integration, and Reusein Multi-disciplinary Design Processes. (PhD), Universityof Twente, Enschede.Woestenenk, K., Bonnema, G. M., Cabrera, A. A. A., &Tomiyama, T. (2012). Capturing Design Process Infor-mation in Complex Product Development. Proceedingsof the Asme International Design Engineering TechnicalConferences and Computers and Information in Engineer-ing Conference, 2011, Vol 2, Pts a and B, 1351–1360.Retrieved from <Go to ISI>://WOS:000324221200139www.egov.gov. (2013). Federal Enterprise ArchitectureFramework.Zachman, J. A. (1987). A Framework for Information-Systems Architecture. Ibm Systems Journal, 26(3), 276–292. Retrieved from <Go to ISI>://WOS:A1987M2500000032395

AMDesigner: An architecture modeling tool for the use in multi-disciplinary design projects

https://ris.utwente.nl/ws/files/5399188/Rajabalinejad-2016-AMDesigner_%20An%20architecture.pdf

AMDesigner: An architecture modeling tool for the use in multi-disciplinary design projects

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information