Software architecture for business

165 71 0
Software architecture for business

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

Lina  Khalid Software Architecture for Business Software Architecture for Business Lina Khalid Software Architecture for Business Lina Khalid ∙ ∙ ISBN 978-3-030-13631-4    ISBN 978-3-030-13632-1 (eBook) https://doi.org/10.1007/978-3-030-13632-1 © Springer Nature Switzerland AG 2020 This work is subject to copyright All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed The use of general descriptive names, registered names, trademarks, service marks, etc in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland Preface Software architecture has many axes when you first begin with it: the business goals of the system, the architecture requirements of the system, etc This book is where you can gather all the knowledge on everything you need to know regarding software architecture This book, which mainly focuses on software architecture and its relation to business, is for students who just start their studies in software engineering field and are in the first course on software architecture; it helps them know the main concepts on software architecture and highlights their thoughts on relating this concept with business context It shows that through building high-quality products, it helps the architects in the business field to think more efficiently in qualities through building the architecture of the products I have been trying to gather the sum of my knowledge in the software architecture field in one place to make it simple, short, yet thorough, and all-inclusive, and here it is, right between your hands This is the perfect guide for the beginners in software architecture The reason why I am proud of what I managed to put together is not only because of the knowledge contained within this book but also because I believe this is suitable for any student especially the beginners in the field So, whether you are taking your first class in software architecture or you are new to a job in this field, this is the book for you This book has two main pillars: the first one is software architecture and its relation to quality and the techniques that are used to gather information for quality, such as QAS and QAW, and the second pillar is the business world and how to build high-quality products through software architecture, which would make them competitive in the market This will be worth your time Good luck! Lina Khalid v Acknowledgment First of all, I thank God for answering my prayers and helping me through my journey Many thanks to the Springer team for guiding me through this process Many thanks go to the light of my life, Leen, for her courage and support and for always giving me a push Thank you, Leen I hope all my efforts yield a well-guiding book for students all over the world Lina vii Contents 1 Introduction����������������������������������������������������������������������������������������������    1 1.1 Architecture Definition ��������������������������������������������������������������������    1 1.2 Basic Types of Architecture��������������������������������������������������������������    2 1.2.1 Software Architecture ����������������������������������������������������������    2 1.2.2 System Architecture��������������������������������������������������������������    5 1.2.3 Enterprise Architecture ��������������������������������������������������������    5 1.2.4 Modern App Architecture for the Enterprise������������������������    7 1.3 Architecture Life Cycle��������������������������������������������������������������������   10 1.3.1 Architecture and Requirements��������������������������������������������   11 1.3.2 The Life Cycle of Architecture ��������������������������������������������   11 1.3.3 Documenting Architecture����������������������������������������������������   13 1.4 Architecture and Technology������������������������������������������������������������   14 1.4.1 Influence of Architecture on Systems ����������������������������������   14 1.5 Architecture’s Role in Business��������������������������������������������������������   16 1.5.1 What Makes Good Architecture in Business?����������������������   17 1.6 Architectural Pattern ������������������������������������������������������������������������   18 1.7 Summary ������������������������������������������������������������������������������������������   19 References��������������������������������������������������������������������������������������������������   20 2 Business Software Architecture (BSA)��������������������������������������������������   21 2.1 Business Software Architecture��������������������������������������������������������   21 2.1.1 Software Architects Need Business Education ��������������������   22 2.1.2 Roles of Software Architects and Business Managers in Business Software Architecture��������������������������������������������   23 2.2 Defining Requirements for Business Architecture����������������������������   24 2.3 Pragmatic Architecture Today����������������������������������������������������������   27 2.4 Business Architecture’s Roles in Management��������������������������������   27 2.5 Summary ������������������������������������������������������������������������������������������   30 References��������������������������������������������������������������������������������������������������   31 ix x Contents 3 Understanding and Dealing with Qualities�������������������������������������������   33 3.1 Definition of Quality ������������������������������������������������������������������������   34 3.2 Software Qualities for the Product����������������������������������������������������   34 3.2.1 Architecture Quality Attribute and Business Quality Attribute ������������������������������������������������������������������   36 3.3 Architecture and Quality������������������������������������������������������������������   37 3.3.1 Architecturally Significant Requirement (ASR)������������������   38 3.3.2 Qualities and Trade-Offs������������������������������������������������������   41 3.4 Gathering Quality Attribute Information������������������������������������������   42 3.4.1 Quality Attribute Scenario (QAS)����������������������������������������   42 3.4.2 Quality Attribute Workshop (QAW) ������������������������������������   45 3.5 Summary ������������������������������������������������������������������������������������������   48 References��������������������������������������������������������������������������������������������������   50 4 Achieving Quality Attribute��������������������������������������������������������������������   51 4.1 Introduction��������������������������������������������������������������������������������������   51 4.2 Architectural Pattern ������������������������������������������������������������������������   52 4.2.1 Patterns and Their Roles in Building Architecture ��������������   53 4.3 Tactics and Quality Attributes����������������������������������������������������������   63 4.3.1 Achieving Quality Through Tactics��������������������������������������   64 4.3.2 The Relationship Between Tactics and Patterns ������������������   67 4.4 Business Pattern��������������������������������������������������������������������������������   68 4.4.1 Pattern for Enterprises����������������������������������������������������������   68 4.5 Importance of Patterns in Business��������������������������������������������������   69 4.6 The SEI Attribute-Driven Design (ADD) Method����������������������������   70 4.7 Summary ������������������������������������������������������������������������������������������   73 References��������������������������������������������������������������������������������������������������   74 5 Managing Business Qualities������������������������������������������������������������������   77 5.1 Business Quality Definition��������������������������������������������������������������   77 5.2 Business Goals����������������������������������������������������������������������������������   78 5.2.1 The Role of the Architect in Achieving the Quality ������������   81 5.3 Definition of Total Quality Management (TQM) ����������������������������   82 5.3.1 Principles of TQM����������������������������������������������������������������   83 5.4 Stakeholders��������������������������������������������������������������������������������������   86 5.4.1 Stakeholders and Business Goals������������������������������������������   87 5.5 Process Improvement������������������������������������������������������������������������   88 5.5.1 Process and Product Quality ������������������������������������������������   88 5.5.2 The Process Improvement Life Cycle����������������������������������   89 5.6 Important Qualities in Business��������������������������������������������������������   91 5.7 Summary ������������������������������������������������������������������������������������������   91 References��������������������������������������������������������������������������������������������������   92 6 Software Product Line (SPL)������������������������������������������������������������������   95 6.1 SPL Definition����������������������������������������������������������������������������������   95 6.2 A Framework for Software Product Line Engineering ��������������������   97 Contents xi 6.3 Architecture and Software Product Line������������������������������������������   99 6.3.1 What Makes a Software Product Line Succeed?������������������  100 6.4 The Quality Attribute of SPL (Variability Quality)��������������������������  101 6.4.1 The Goal of Variability ��������������������������������������������������������  102 6.4.2 Variation Mechanism������������������������������������������������������������  103 6.5 Evaluating a Product Line Architecture��������������������������������������������  104 6.6 Summary ������������������������������������������������������������������������������������������  105 References��������������������������������������������������������������������������������������������������  106 7 Internet of Things (IoT)��������������������������������������������������������������������������  107 7.1 IoT Definition������������������������������������������������������������������������������������  107 7.2 Architecture and IoT ������������������������������������������������������������������������  111 7.3 Basic Qualities of IoT ����������������������������������������������������������������������  111 7.3.1 Interoperability Quality��������������������������������������������������������  112 7.3.2 Modifiability Quality������������������������������������������������������������  115 7.4 DYAMAND: Case Study������������������������������������������������������������������  117 7.4.1 DYAMAND Requirement����������������������������������������������������  119 7.4.2 DYAMAND Architecture������������������������������������������������������  120 7.5 Evaluating IoT Architecture��������������������������������������������������������������  123 7.6 Summary ������������������������������������������������������������������������������������������  127 References��������������������������������������������������������������������������������������������������  127 8 Service-Oriented Business Architecture (SOBA)����������������������������������  129 8.1 Definition of Service-Oriented Business Architecture (SOBA) ������  130 8.2 Basic Qualities in SOBA������������������������������������������������������������������  132 8.2.1 Availability����������������������������������������������������������������������������  133 8.2.2 Scalability ����������������������������������������������������������������������������  135 8.3 The Impact of Service-Oriented Architecture on Quality Attribute and Business Goals������������������������������������������������������������  136 8.4 Service-Oriented Business Architecture and the Evaluation Method����������������������������������������������������������������������������������������������  137 8.5 Summary ������������������������������������������������������������������������������������������  142 References��������������������������������������������������������������������������������������������������  142 Conclusion Thoughts ��������������������������������������������������������������������������������������  145 Appendix A ������������������������������������������������������������������������������������������������������  147 Appendix B ������������������������������������������������������������������������������������������������������  151 Appendix C ������������������������������������������������������������������������������������������������������  153 Index������������������������������������������������������������������������������������������������������������������  157 Dealing With Quality QAS QAW Chapter Patterns and Tactics Chapter Architecture Definition and Types Chapter1 SPL, IoT, SOBA Systems Chapters 6, 7, Business Software Architecture Chapter2 Software Architecture for Business The Book Managing business quality Principles of TQM Chapter5 A quick tour xiii Conclusion Thoughts Now at last I want to conclude the main thoughts that I want you to know through beginning your future in software architecture especially if you are just beginning your study in this field or just beginning your first day in your job as an architect: • First: qualities are the basic part for any individual, company, and organization that need to start building their products, because this will make the competition between products or even between the people whose responsibility is building the products in the market It is the main target to building any system • Second: knowing the patterns and tactics As beginning with the first thought, the quality is the basic thing that all must focus on, and the second thought that you must know is that gaining the quality can be done through other stages in the life cycle Here the focus is on software architecture stage because the title of this book is going around this stage And because I talked especially on software architecture and its relation to building high-quality products, then you need to know the architectural patterns and their tactics to use the most appropriate of them to have the high-quality products and also make a trade-off between qualities in the same product • Third: stakeholders Through years ago I read many books and article papers and attend conferences on software architecture; through that I saw the important advice from professionals; and this advice says: know your stakeholders Knowing the stakeholder is a very important part to any architect because you as an architect can extract the goals that they want from the product that you can go through this road to reach the quality • Fourth: evaluation It is very important to any architecture because it avoid architectures from disaster To put it in a different way, if you were building a house, you wouldn’t proceed without carefully looking at the blueprints before building began It is also the right thing to know the appropriate method according to the quality of the product as what said through this book but in general ATAM method is used as an evaluation method Also you must know that the evaluation will tell you that the architecture is suitable according with one goal (or set of © Springer Nature Switzerland AG 2020 L Khalid, Software Architecture for Business, https://doi.org/10.1007/978-3-030-13632-1 145 146 Conclusion Thoughts goals) and according to other qualities there is a problem, sometimes one goal is important than another sometimes a conflict occurs between qualities, the manager of the project will have the decision to make if the architecture evaluates good in some areas and not evaluated very well in other area • Also you showed that SAAM method focuses on modifiability quality in its different forms (such as portability, subsetability, and variability) and functionality, while ARID method provides a deep understanding about the suitability of part of the architecture to be used by developer to complete their responsibilities That is why architecture evaluation methods can be choosing according to the qualities that are related to that architecture • In short, architecture evaluation produces better architectures Finally I hope you have the basic stone to start your journey in software architecture and its relation to building high-quality products Appendix A General Scenario for Modifiability Artifact What to be changed: code, interfaces, data Source End user System Administrator developer Stimulus The change to be made:Add/ Delete/Modify functions A change can be made to quality also Environment Response When the change can be made: in all stages of life cycle Make ,test and deploy modification Response measure Time and money is the most measure Concrete Scenario for Modifiability Artifact code Source developer Stimulus The change to UI Environment At a design time © Springer Nature Switzerland AG 2020 L Khalid, Software Architecture for Business, https://doi.org/10.1007/978-3-030-13632-1 Response Change made and test Response measure In three hours 147 Appendix A 148 Role of General Scenario for Performance Artifact System, or one or more components in system Source Internal or extenal to the sytem Environment The system can be in various operational mode: as for example normal mode, emergency mode Stimulus Arrival events Response The system must process the arriving events Response measure The time taken to process the arriving events:latency,jitter … Concrete Scenario for Performance Artifact System Source users Stimulus Initiate event(transaction) Environment Normal operation Response Processed transactions Response measure Latency for two seconds General Scenario for Security Artifact Service of System, data within system, data produced or consumed by system Source The source either human or another system Stimulus Attack happen: example attempt to modify ,delete ,display data Environment The attack come in any mode of system example normal mode, overload mode Response Process events Change the level of service Response measure Response of system example: recovery time Appendix A 149 Concrete Scenario for Security Artifact Data within the ystem Source Distinguished employee from remote place Stimulus Attempts to modify pay rate Environment Normal operation Response System maintains audit trail Response measure Resore correct data within a day General Scenario for Testability Artifact Part of system being tested Source Could be human or automated tester Stimulus Set of tests through completion of coding increment example: service Environment Happen at: development time ,compile time, deployment time ,run time, design time, integration time Response Controlled the system to perform test and the result can be observed Response measure Effort to find a fault effort o achieve a coverage %, Probability of fault being revealed by next stage, Time to carry out tests, Reduction in risks Time to prepare test environment Effort to detect fault And so on 150 Appendix A Concrete Scenario for Testability Artifact Code part Source Unit tester Stimulus completion of coding unit Environment Development time Response Captured results Response measure Coverage 90% at hours General Scenario for Usability Artifact System or part of the system that interacting by user Source End user Stimulus Try to use the system efficiently Learn using the system Adapt the system Minimize the effect of errors Configure system Response Environment run time or configration time Providing the user’s need of features Or predict the user's need Response measure Task time Number of errors Number of finished tasks User satisfaction Percentage of successful operation to the total amount And so on Concrete Scenario for Usability Artifact system Source user Stimulus Download a new application Environment run time Response Uses applicatin productivity Response measure Within two minutes experiments Appendix B Software structure Decomposition Useful for Resource allocation and project structuring and planning; information hiding, encapsulation; configuration control Uses Module Uses Engineering subsets; engineering extensions Incremental development; Layered Layer Requires the correct presence of; implementing systems on top of “virtual machines” uses the services of; provides abstraction to In object-oriented design Class Classes, objects Is an instance of; systems shares access methods of C&C Service Service, Run concurrently Scheduling analysis, structure registry, others with, etc performance analysis Concurrency Process, thread Can run in parallel Identifying locations where resource contention exists, where threads may fork, join, be created or be killed Allocated to; Performance, availability, Allocation Deployment Components, migrates to security analysis structure hardware elements Implementation Modules, file Stored in Configuration control, structure integration, test activities Assigned to Project management, best Work Modules, use of expertise, assignment organizational management of unit commonality Module structure Element types Module Relation Is a sub module of Architectural structure for the system © Springer Nature Switzerland AG 2020 L Khalid, Software Architecture for Business, https://doi.org/10.1007/978-3-030-13632-1 151 Appendix C ATAM (Architecture Trade-off Analysis Method) First of all, ATAM gets its name because it reveals on how well an architecture satisfies the quality goals, and the most important thing is how trade-off between qualities has been used for over a decade to evaluate software architectures and draws its technique from three areas: • The architectural style concepts • The quality attributes analysis communities • SAAM method the predecessor method to the ATAM ATAM steps can be separated into four main groups Presentation: exchange the information through the presentation which includes: Present the ATAM: evaluation leader introduce the method to the participate Present the business driver: the project manager or customer describes the business goals that motivated the development and then what is the main architectural driver (such as time to market) Present the architecture: here, the role of architect is to describe the architecture and focus his attention on how it addresses the business driver Investigation and analysis Identify the architectural approaches: the approaches of architecture are identified by architect but not analyzed Generate the utility tree: the quality attribute of system is elicited and specified down to the level of scenarios, stimulus, and response and prioritized Analyze the architectural approach: based on the high priority in previous step, the architectural approaches that address the scenario will be analyzed Here, risk, sensitivity point, and non-risk trade-off will be identified in this step © Springer Nature Switzerland AG 2020 L Khalid, Software Architecture for Business, https://doi.org/10.1007/978-3-030-13632-1 153 Appendix C 154 Testing Brainstorming and prioritize scenario: the set of scenario that elicited earlier will be prioritized through voting process involving all the stakeholders Analyze the architectural approaches: in this step, reiteration of the activities in step occurs, but high-ranked scenarios from step are used Those scenarios are supposed to be the test cases to confirm the analysis performed thus far Reporting Present the result based on the information collected during the steps, and then the results will be presented to the stakeholders These steps can be carried out through the following phases: Phase Activity Preparation Evaluation from steps to Evaluation from steps to Process improvement and delivery According to quality, ATAM is not oriented to any specific type of quality SAAM (the Software Architecture Analysis Method) It is a simple method and good place to start if this is the first time you evaluate and architecture, especially if you work on modifiability and functionality The output tangible results from SAAM evaluation are: • Mapping onto scenarios that represent possible future changes to the system • Understanding the functionality of the system SAAM steps are: Develop scenario: these scenarios represent tasks related to different roles of stakeholders; these scenarios are all brainstorming exercise, and also they are collected in two or more elicitations Describe architecture: describing the architectures should be through notations that will be understand by parties and must specify data components with related connections and system’s computation, and all these will take in the form of natural language or some other formal specification Classify/prioritize scenarios: in SAAM, scenarios are classified into direct and indirect scenarios Prioritization is done by choosing the most important scenarios and that is done by stakeholders through voting process Individually evaluate indirect scenario: chosen scenarios are mapped onto the architectural description According to direct scenarios, the architect shows how Appendix C 155 these scenarios are executed by architecture On the other hand, in indirect ­scenarios, the architect should describe how the architecture needs to be changed in order to accommodate the scenarios Assess scenario interaction: interaction scenarios are called to the indirect scenarios that require changes to a single component of architecture These types of scenarios are important for two reasons: first reason is it depicts allocation of functionality to the product’s design Second important reason is that it can expose the architecture not documented to the right level of structural decomposition Create overall evaluation: at the final stage, a weight is assigned to each scenario for the reason of showing the related importance to the success of system This weight usually attaches to the business goals that support the scenarios Notes • Step and done on interleaved way or on several iterations • There are two important concepts in these iterations, and those are direct and indirect scenarios Scenarios represent tasks relevant to different roles such as developer, maintainer, customer, etc Direct scenarios are those scenarios that are specified by the architecture through the execution of the system Such types of scenarios are increasing the understanding of the architecture to the stakeholders and allow the systematic exploration of their architectural qualities On the other hand, there is an indirect scenario which defines as that requires a modification to the architecture to be satisfied It is those scenarios that play as a central role to the measurements of the degree to which an architecture can hold evolutionary changes that are important to the stakeholder The indirect scenarios measure the suitability for continuing use throughout the lifetime of the family ARID (Active Reviewers for the Intermediate Design) It is a method that used to evaluate the architecture partially or in the intermediate designs when all the architecture passes through This method lies at the intersection between ATAM and ADRs (active design reviewers) methods It consists of nine steps going through two phases Phase 1: Rehearsal In this phase, a meeting between the lead designer and review facilitator to prepare for exercise Step 1: identify the reviewers—the reviewers of the ARID are the design’s stakeholders 156 Appendix C Step2: prepare the design briefing—the designers organize a brief explanation of the design The goal is to present the design in a good so that members can use it in a sufficient way Step3: prepare the seed scenarios—here, designer and the review facilitator present a set of seed scenarios; the aim is roughly a dozen scenarios Step 4: prepare the materials—this step is the preparation to phase by preparing copies of the presentation, scenarios, and review agenda to the reviewers during phase Phase 2: Review Step 5: present ARID—the explanation of the steps of ARID to the participants is done by review facilitator Step 6: present the design—the suitability of the design is the goal of this step The lead designer gives an overview presentation with examples Step 7: brainstorm and prioritize scenarios—this session is just for brainstorming and prioritizes scenarios Voting process is done through process, and the most voted scenarios received are used to test the design for testability Step 8: apply the scenarios—when received the most voted scenarios, the facilitator ask reviewers to expertise the code that uses the design services to solve the problem posed in the scenario whenever the group went to the wrong direction they will be stopped to get the group moving again by providing whatever information is supposed it will be necessary Step 9: summarize—recounting the list of issues is done by facilitator; ask the participants for their opinions and thank them for their participations Note ARD method relies on actively engaging reviewers by assigning them review tasks that are structured; it is used to evaluate detailed design of coherent units of software for example modules or components According to quality, ARID is used for suitability of the design approach Index A Allocation structure, 52 Application layer, 110 Architectural patterns broker pattern, 54, 55 client-server, 57, 58 definition of, 52 elements, 52 layered pattern, 53, 54 module patterns, 53 multitier pattern, 60 MVC pattern, 55, 56 pipe-filter, 56, 57 publish subscriber pattern, 61–63, 74 SOA, 59, 60 software architecture structures, 52 types of structures, 52 Architectural structure, 51, 52, 71, 74 Architectural style, 74 Architecturally Significant Requirements (ASR), 11 business goals, 39 interviewing stakeholders, 38 requirement documentation, 40 system’s requirement, 38 utility tree, 40 Architecture definition, documentation, 13, 14 life cycle of, 11, 13 pattern allocation, 18 component and connector, 18 layers, 18 and requirements, 11 © Springer Nature Switzerland AG 2020 L Khalid, Software Architecture for Business, https://doi.org/10.1007/978-3-030-13632-1 role of architect of technical infrastructure, 16 business architect, 16 business manager, 16 business strategy, 16 enterprise architect, 16 productivity and efficiency, 16 solution architect, 16 types, 17 and technology influence of, 14, 15 Architecture drivers, 71 Architecture Influence Cycle (AIC), 15 Architecture Reviews for Intermediate Design (ARID), 104 Architecture Trade-off Analysis Method (ATAM), 13, 41, 104 Attribute-Driven Design (ADD), 11, 16, 70, 71, 73 B Business architecture, Business governance, 130, 142 Business managers, 23, 24 Business pattern, 68–70 Business Process Framework (BPF), 123 Business quality basic categories, 92 benefits, 91 definition, 77, 78 goals, 78–81 types of, 91 Business software architecture (BSA) business education, 22 business managers, 23, 24 157 158 Business software architecture (BSA) (cont.) definition, 21 measurement, 30 pragmatic architect, 27 requirements, 24, 26 role, business architect, 29 role, management, 27, 28 C Client-server pattern, 18 Cloud computing, 108 Commercial off the Shelf (COTS) software, 78, 97 Competence center and platform pattern, 18 Component and connector structure, 52 Containers-as-a-Service (CaaS), Cost benefit analysis method (CBA), 23 Cyclomatic complexity, 35 D Docker architecture, 9, 10 Dynamic Adaptive Management of Network and Devices (DYAMAND) application developers, 117 architecture, 120, 121, 123 functions, 118 lack of interoperability, 117 plug-in architecture, 118 software requirement, 119 E Enterprise architecture, 5, business architecture, characteristics, fundamental technology and process structure, modern app architecture, 7, organization/collaborative collections, role of stakeholder, Evaluation, 145, 146 Event Driven Architecture (EDA), Index Global System for Mobile communication (GSM), 109 Graphical user interfaces (GUIs), 55 I IBM’s Research Division, 131 Integrity, Internet of Things (IoT) application layer, 110 cloud computing, 108 Cs impact, business and society, 111 evaluation, 123, 125, 126 fundamental characteristics, 108 gateways and networks, 110 integration of information technology, 107 interoperability quality, 112, 113, 115 IPv6, 108 management service layer, 110 modifiability quality, 115, 116 RFID, 108 smart device/sensor layer, 109 software architecture, 111 type of network, 107 Internet Protocol version (IPv6), 108 L Local area network (LAN), 109 M Management service layer, 110 Manufacturing and Service Organizations, 82 Marketability, 78 Marketecture, 14, 19 Microkernel pattern, 123 Microservices, Model-View-Controller (MVC) pattern, 55, 56, 141 Modularity, Module structure, 52 Multitier pattern, 18, 60 F First come first service (FCFS), 67 N Networks, 110 Non Functional Requirements (NFR) Framework, 41 G Gateways, 110 General Event Notification Architecture (GENA), 118 O Object Management Group (OMG), 24 Operationalizations, 49 Order Processing Center (OPC), 139 Index P Pedigree Attribute eLicitation Method (PALM), 80 Personal area network (PAN), 109 Plan-Do-Study-Act (PDSA), 83 Publish subscriber pattern, 61–63, 74 Q Qualities, 145 Quality attribute ADD, 70, 71, 73 benefit of pattern, 69 definition, 34 implementation/deployment, 37 product line scope, 101 software architecture and qualities, 37, 38 software product architecture and business, 36, 37 customer satisfaction, 36 cyclomatic complexity, 35 definition, 34 external and internal, 35 predictability, 36 reputation, 36 use of systematic software measurement, 36 tactics parameters, 66 vs patterns, 67 quality attributes, 64 queuing model, performance quality, 66, 67 stimulus and response, 64 support system initiative, 66 support user initiative, 64 usability, 66 and trade-offs, 41 variability, 102 variants goal of, 102 user interface, 102 variation mechanism, 103 variation points, 102 Quality Attribute Scenario (QAS), 39, 42–44 Quality attribute workshop (QAW), 11 advantages, 48 architectural plan and presentation, 46 business /mission presentation, 46 identification of architectural drivers, 46 presentation and introductions, 46 scenario brainstorming, 47 scenario consolidation, 47 159 scenario prioritization, 47 scenario refinement, 47 technique of elicitation, 45 Quality function deployment (QFD), 84 Quality model (QM), 126 R Radio Frequency Identification Devices (RFID), 108 Return on investment (ROI), 23, 36, 102 S Service Discovery Protocols (SDPs), 117 Service oriented architecture (SOA) pattern, 59, 60 Service Oriented Business Architecture (SOBA) basic qualities availability, 133, 134 business functionality, 132 requirements, 132 scalability, 135 business technology, 131 definition, 130 evaluation method Adventure Builder, 139 architectural analysis, performance quality, 141 ATAM method, 138 hub-and-spoke, 141 phases, 139 quality attributes, 138 software architecture, 137 stakeholders, 137 quality attribute and business goals, 136, 137 quality attributes, 130 Service-Level Agreement (SLA), 133 Service-Oriented Architecture (SOA), 130 Shared-data/repository pattern, 18 Smart device/sensor layer, 109 Software architecture abstraction, algorithms and data structures, definition, functional and non-functional requirements, modern, software system, structure, Software Architecture Analysis Method (SAAM), 41, 104 160 Software product line (SPL) architecture architects, 101 architectural design, 100 artifact reuse, 100, 101 modeling and analysis, 100 project planning, 100 requirements, 100 software elements, 100 testing, 100 definition, 95, 96 framework core assets development, 97, 98 essential activities, 97 management, 99 product development activity, 98 software community, 97 technical and organizational management, 97 product line architecture, 104, 105 Software Quality for the Product (SQP), 34 Specific, measurable, attainable, realistic, and time (SMART) bound, 78 Stakeholders, 145 business goals, 87 definition, 86 process and product quality, 88 process improvement, 88 process improvement life cycle, 89, 90 and roles, 87 System architecture, Index T Tactics, 145 Telecom Operation Map (TM), 123 The System Under Consideration (TSUC), 81 Total quality management (TQM) benefits, 82 definitions, 82 Manufacturing and Service Organizations, 82 principles continuous improvement, 83 customer-focus, 83 employee empowerment, 84 managing supplier quality, 85 process management, 85 product design, 84 use of quality tools, 85 service organizations sector, 82 U Unified Modeling Language (UML), 13 Universal Plug and Play (UPnP), 117 V Virtual machine monitor (VMM), W Web services, 97 Wide area network (WAN), 109 Wireless sensor networks (WSNs), 109 ... for business architecture • Software architect and business managers responsibilities in business software architecture • The requirements for business architecture • The concept of pragmatic architecture. .. definitions of the types of architecture, system architecture, software architecture, enterprise architecture, and business architecture, but it focuses mainly on software architecture There are many... called software architecture Many other types of architecture are related to software architecture, but they are broader than software architecture These include system architecture, enterprise architecture,

Ngày đăng: 03/01/2020, 13:34

Từ khóa liên quan

Mục lục

  • Preface

  • Acknowledgment

  • Contents

  • Chapter 1: Introduction

    • 1.1 Architecture Definition

    • 1.2 Basic Types of Architecture

      • 1.2.1 Software Architecture

        • 1.2.1.1 Modern Software Architecture

        • 1.2.2 System Architecture

        • 1.2.3 Enterprise Architecture

          • 1.2.3.1 Business Architecture

          • 1.2.4 Modern App Architecture for the Enterprise

          • 1.3 Architecture Life Cycle

            • 1.3.1 Architecture and Requirements

            • 1.3.2 The Life Cycle of Architecture

            • 1.3.3 Documenting Architecture

            • 1.4 Architecture and Technology

              • 1.4.1 Influence of Architecture on Systems

              • 1.5 Architecture’s Role in Business

                • 1.5.1 What Makes Good Architecture in Business?

                • 1.6 Architectural Pattern

                • 1.7 Summary

                • References

                  • Further Reading

                  • Chapter 2: Business Software Architecture (BSA)

                    • 2.1 Business Software Architecture

                      • 2.1.1 Software Architects Need Business Education

                      • 2.1.2 Roles of Software Architects and Business Managers in Business Software Architecture

                      • 2.2 Defining Requirements for Business Architecture

                      • 2.3 Pragmatic Architecture Today

Tài liệu cùng người dùng

  • Đang cập nhật ...

Tài liệu liên quan