{"title":"评估工业中的简单依赖关系图","authors":"J. Savolainen, Varvana Myllärniemi, T. Männistö","doi":"10.1109/WICSA.2011.36","DOIUrl":null,"url":null,"abstract":"The research and practice on designing and analyzing software architectures has evolved considerably during the past decade. In particular, more precise architecture modeling methods have reached industrial practice. Despite this, simple dependency diagrams are still widely used ease communication with non-technical stakeholders, to reduce need for domain knowledge, and to make initial design before detailed architecture phase. Based on our experience, seasoned architects can easily find potential architectural problems in these descriptions. In this paper, we describe a representative set of potentially problematic structures in dependency diagrams to raise relevant questions on the decisions made to create the software architecture.","PeriodicalId":234615,"journal":{"name":"2011 Ninth Working IEEE/IFIP Conference on Software Architecture","volume":"29 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2011-06-20","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"0","resultStr":"{\"title\":\"Evaluating Simple Dependency Diagrams in Industry\",\"authors\":\"J. Savolainen, Varvana Myllärniemi, T. Männistö\",\"doi\":\"10.1109/WICSA.2011.36\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"The research and practice on designing and analyzing software architectures has evolved considerably during the past decade. In particular, more precise architecture modeling methods have reached industrial practice. Despite this, simple dependency diagrams are still widely used ease communication with non-technical stakeholders, to reduce need for domain knowledge, and to make initial design before detailed architecture phase. Based on our experience, seasoned architects can easily find potential architectural problems in these descriptions. In this paper, we describe a representative set of potentially problematic structures in dependency diagrams to raise relevant questions on the decisions made to create the software architecture.\",\"PeriodicalId\":234615,\"journal\":{\"name\":\"2011 Ninth Working IEEE/IFIP Conference on Software Architecture\",\"volume\":\"29 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2011-06-20\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"0\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"2011 Ninth Working IEEE/IFIP Conference on Software Architecture\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1109/WICSA.2011.36\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"2011 Ninth Working IEEE/IFIP Conference on Software Architecture","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/WICSA.2011.36","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
The research and practice on designing and analyzing software architectures has evolved considerably during the past decade. In particular, more precise architecture modeling methods have reached industrial practice. Despite this, simple dependency diagrams are still widely used ease communication with non-technical stakeholders, to reduce need for domain knowledge, and to make initial design before detailed architecture phase. Based on our experience, seasoned architects can easily find potential architectural problems in these descriptions. In this paper, we describe a representative set of potentially problematic structures in dependency diagrams to raise relevant questions on the decisions made to create the software architecture.