Скачать презентацию Seminar at Beijing University Deriving and Analysing the Скачать презентацию Seminar at Beijing University Deriving and Analysing the

da090eff0959255e0fe3f86477cc99e4.ppt

  • Количество слайдов: 46

Seminar at Beijing University Deriving and Analysing the Quality of Software Architectural Designs Hong Seminar at Beijing University Deriving and Analysing the Quality of Software Architectural Designs Hong Zhu Department of Computing, Oxford Brookes University, Oxford OX 33 1 HX, UK Email: [email protected] ac. uk Sept. 9, 2009 1

Outline Sept. 9, 2009 Ø Overview of existing work and open problems Ø Our Outline Sept. 9, 2009 Ø Overview of existing work and open problems Ø Our approach u. Graphic model of software quality u. Derivation of software quality model from design u. Analysis of quality models Ø Conclusion u. Comparison u. Future with related works work Seminar at Beijing University 2

The Notion of Quality Ø Quality, in particular software quality, is an elusive concept The Notion of Quality Ø Quality, in particular software quality, is an elusive concept and varying from people to people. Ø Garvin’s definitions of quality Sept. 9, 2009 u Transcendent view: Quality is universally recognisable. It is related to a comparison of features and characteristics of products. u Product-based view: Quality is a precise and measurable variable. Differences in quality reflect the differences in quantities of some product attributes. u User-based view: Quality is the fitness of intended uses. u Manufacturing-based view: Quality is conformation to the specifications. u Value-based view: A quality product is one that provides performance at an acceptable price or conformance at an acceptable cost. Seminar at Beijing University 3

Software Quality Models Ø Models about software quality in terms of Sept. 9, 2009 Software Quality Models Ø Models about software quality in terms of Sept. 9, 2009 u The factors that affect software quality • Attributes directly indicate the quality of he system, e. g. reliability, correctness, user friendliness, etc. • Attributes indirectly related to quality, e. g. internal complexity, etc. u The interrelations between the factors • Causality models: Ñ Causal relationship, in terms of stereo-type relations • Quantitative models: Ñ Quantitative relations expressed as numerical functions, Ñ Numerical values of the basic attributes are given, e. g. through using metrics/measurements Ñ The overall quality in an attribute on a more high level of abstraction is calculated numerically Seminar at Beijing University 4

Hierarchical Models of SQ Ø A set of quality related properties organised into a Hierarchical Models of SQ Ø A set of quality related properties organised into a hierarchical structure Sept. 9, 2009 u. E. g. decompose quality into a number of quality attributes and attributes into a number of factors, and then a number of measures, etc. u. Positive causal relationship is represented Ø Examples: u. Mc. Call model (1977) u. Boehm model (1978) u. ISO model (1992) u. Bansiya-Davis model of OO designs (2002), etc. Seminar at Beijing University 5

Sept. 9, 2009 Mc. Call’s Model Maintainability: Can I fix it? Flexibility: Can I Sept. 9, 2009 Mc. Call’s Model Maintainability: Can I fix it? Flexibility: Can I change it? Testability: Product Can I test it? revision transition Product operations Portability: Will I be able to use it on another machine? Reusability: Will I be able to reuse some of the software? Interoperatability: Will I be able to interface it with another machine / software? Correctness: Does it do what I want? Reliability: Does it do it accurately all the time? Efficiency: Will it run on my machine as well as it can? Integrity: Is it secure? Usability: Can I run it? Seminar at Beijing University 6

ISO 9126 Model Functionality Sept. 9, 2009 Reliability Software quality Usability Efficiency Maintainability Portability ISO 9126 Model Functionality Sept. 9, 2009 Reliability Software quality Usability Efficiency Maintainability Portability Seminar at Beijing University Suitability Accuracy Interoperability Compliance Security Maturity Fault tolerance Recoverability Understandability Learnability Operability Time behaviour Resource behaviour Analysability Changeability Stability Testability Adaptability Installability Conformance 7 Replaceability

Relational Models of SQ Ø A quality model consists of: Sept. 9, 2009 u. Relational Models of SQ Ø A quality model consists of: Sept. 9, 2009 u. A number of quality attributes and factors, etc. set of stereo types of relationships between them, normally include • Positive relation: High on one aspect of quality implies inevitably high on the other • Negative relation: High on one aspect of quality implies inevitably low on the other • Neutral relation: High or low on one aspect of quality does not imply on the other aspect the quality is high or low. Ø Examples: u Perry model (1991) u Gillies model (1992, 1997) Seminar at Beijing University 8

Perry’s Model Correctness C Reliability Sept. 9, 2009 Efficiency Direct R Inverse E Integrity Perry’s Model Correctness C Reliability Sept. 9, 2009 Efficiency Direct R Inverse E Integrity Neutral I Usability U Maintainability Testability Flexibility Portability M T F P Reusability R Interoperability Seminar at Beijing University I 9

Roles in Software Development Ø Understanding software quality Sept. 9, 2009 u. To measure Roles in Software Development Ø Understanding software quality Sept. 9, 2009 u. To measure an existing system’s quality, u. To predict a system’s quality during development u. To analyse quality problems during development and/or in operation of a systems Ø Guidelines to development activities u. To elicit users’ requirements on software quality u. To perform quality assurance activities in software development and maintenance Seminar at Beijing University 10

Key Features of Existing SQ Models Sept. 9, 2009 Feature Universal Simplicity Black-box Empirical Key Features of Existing SQ Models Sept. 9, 2009 Feature Universal Simplicity Black-box Empirical Pros Applicable to all software systems Stereo types of relationships between quality attributes Cons Not address system specific issues Incapable of dealing with complicated relationships between quality attributes Treat software systems Provide little help to the as black-boxes designers to consider system’s structure Developed-based on Cannot be validated or empirical knowledge verified of its correctness from experiences Seminar at Beijing University 11

Our Approach Ø Representing software quality models in a diagrammatic notation (Zhang, Zhu, et Our Approach Ø Representing software quality models in a diagrammatic notation (Zhang, Zhu, et al. 2002) to improve expressiveness of quality models to represent complicated relationships between factors u to associate quality features with the structure of the system Sept. 9, 2009 u Ø Deriving software quality models from architectural designs (Zhang, et al. 2002, Zhu, 2005) u to systematically derive quality models from software architectural designs by employing extended hazard analysis concepts and techniques Ø Automating the analysis of quality models to help software designers (Zhang, et al, 2006 a, 2006 b) u to perform various analysis tasks based on graphic quality models by developing and using automated software tools Seminar at Beijing University 12

Graphic Notation for Modelling SQ Sept. 9, 2009 Subject [+|-] Property Phenomenon [+ | Graphic Notation for Modelling SQ Sept. 9, 2009 Subject [+|-] Property Phenomenon [+ | - ] Annotation of Reasons Client side - Compatibility Font size too small to be illegible. Node: representing quality carrying properties and quality attributes and observable phenomena Link without annotation: representing logic relations between the nodes. Link with Annotation: providing additional information of the rationale of the relation between nodes. Interface is not displayed properly Node A Seminar at Beijing University Link System - Usability Difficult to operate Node B 13

Example: Web-based Applications HTML files + Well Structured Large size Sept. 9, 2009 Less Example: Web-based Applications HTML files + Well Structured Large size Sept. 9, 2009 Less nodes means less links Need long time to transmit the files Web Server - Responsiveness Long response time Client side - Compatibility Font size too small to be illegible when displayed user’s platform HTML files + Navigability Small number of hyperlinks Simpler hyperlink network usually easier to navigate System + Usability Easy to find required info Server side + Load Highly demanded Web page cannot be displayed properly Files are considered as unavailable when time-out System - Usability Cannot find required info Seminar at Beijing University Server side - Performance Execution speed is slow HTML files - Correctness Contains broken links Unable to obtain files through hyperlinks Online Help - Availability Not available Unable to get help when experiencing difficulty 14

Deriving Quality Models: The HASARD Methods Ø HASARD: Hazard Analysis of Software ARchitectural Design Deriving Quality Models: The HASARD Methods Ø HASARD: Hazard Analysis of Software ARchitectural Design Ø Input: A software architectural model Ø Output: A quality model in graphic notation Ø Process: Hazard identification A hazard identification method is applied to identify all quality sensitive observable phenomena of the components, connectors, the system, etc. u Cause-consequence analysis The causal relationships between the identified hazards are recognized u Model assembling The information obtained in the previous steps are assembled together and represented in the graphical notation u Quality concern recognition The quality carrying properties/quality attributes that a phenomenon demonstrates are recognized according to the nature of the phenomenon Sept. 9, 2009 u Seminar at Beijing University 15

Hazard Identification Ø Extended Hazard and Operability Studies (HAZOP) Sept. 9, 2009 u. The Hazard Identification Ø Extended Hazard and Operability Studies (HAZOP) Sept. 9, 2009 u. The method relies on determining answers to questions of what-if nature. u. By applying a set of guide words systematically to develop a collection of what-if questions. u. They are applied to the attributes of various components and connectors of the system being studied. u. If a deviation from the normal working of the component is credible, the behaviour of the component is considered as a possible hazard. Seminar at Beijing University 16

Guide Words for Software Hazard Identification Guide Applicable word attribute Date/control signals No data Guide Words for Software Hazard Identification Guide Applicable word attribute Date/control signals No data / control signal exchanged; No data / control signals produced/received. Component property/ function The component / connector does not have the designed property / function. Component / connector The system does not contain the component / connector. More Quantitative parameters The value of the parameter is too large. Less Quantitative parameters The value of the parameter is too small. Sept. 9, 2009 No Interpretations Seminar at Beijing University 17

As well as Sept. 9, 2009 Redundant data sent, or event/activity occurred in addition As well as Sept. 9, 2009 Redundant data sent, or event/activity occurred in addition to the intended ones. Component / connector Other components / connectors are added in addition to the intended ones. Structured data Only a part of the data produced, stored or received. Structure events Part of Event or activity Only a part of the events happened. Reverse Direction of flow Event Other than The information flow in the opposite direction. The opposite event happened. Data/control signals, Incorrect data / control signals produced; quantitative/qualitative The parameter has a value different from the parameters design. Component/system’s function or property The component has a functionality / property different from the designed. Component/ connector Other kind of component / connector is contained. Seminar at Beijing University 18

Sept. 9, 2009 Early Periodical events The event happened earlier than expected. Late Periodical Sept. 9, 2009 Early Periodical events The event happened earlier than expected. Late Periodical events The event happened later than expected. Before Temporal orders The event happened in the order earlier than designed. After The event happened in the order later than designed. Temporal orders Seminar at Beijing University 19

Example: Internet Connection Guide Hazard/Failure mode Causes word Consequences Sept. 9, 2009 No The Example: Internet Connection Guide Hazard/Failure mode Causes word Consequences Sept. 9, 2009 No The internet connection passes no messages between the client and server. Physically disconnected; Traffic jam; Software failure; Network server down. Client cannot communicate with the server. More messages are delivered than the clients and the server send out, e. g. duplicated messages. Hacker’s attack; Heavy traffic on the Internet caused resending packages. System clash; Overload on the server or the client. Less Fewer messages are delivered than the server and the clients send out, i. e. lost messages. Discontinued Internet connection; Heavy traffic on the Internet; Software failure. Incomplete transactions; System clash; Damage the integrity of the data and program on the server and/or client. Seminar at Beijing University 20

Messages are delivered Hacker’s attack; to other destinations in Software failure. addition to the Messages are delivered Hacker’s attack; to other destinations in Software failure. addition to the designated receiver. Leak of sensitive information. Part of Sept. 9, 2009 As well as Only a part of the packets of a message is delivered to the destination client or server. Software failure; Production of incorrect computation results if incompleteness is not detected. Other than A message not from the Hacker’s attack; Other client (or the server) is software system’s passed to the server (or failure client). System failure; Damage the integrity of the data and the program. Other than The message is in a different format. System failure. Discontinued Internet connection; Heavy traffic on the Internet; Software failure. The client or the server is modified; Fault in the software. Seminar at Beijing University 21

Cause-Consequence Analysis Ø It aims at understanding the causal relationships between hazards. Ø It Cause-Consequence Analysis Ø It aims at understanding the causal relationships between hazards. Ø It can be performed backward or forward, or a combination of both. Sept. 9, 2009 u Forward analysis • Search for the potential effects, i. e. consequences, of a hazard until the consequence is terminal. • A hazard or failure mode is terminal: Ñ if it does not affect any other component of the system or Ñ If It does not cause any other hazards/failures. Ñ if we are not interested in its further consequences. u Backward analysis • Search for the causes of a hazard until the hazard is primitive. • A hazard or failure mode is primitive: Ñ if its causes cannot be further identified without additional knowledge about the system Ñ if we are not interested in its causes Seminar at Beijing University 22

Sept. 9, 2009 Results of Cause-Consequence Analysis Seminar at Beijing University 23 Sept. 9, 2009 Results of Cause-Consequence Analysis Seminar at Beijing University 23

Constructing Graphic Quality Model Ø Input: The records of the cause-consequence analysis Sept. 9, Constructing Graphic Quality Model Ø Input: The records of the cause-consequence analysis Sept. 9, 2009 Ø Output: A partially completed graphical representation of quality model Ø The transformation: u Each record of the hazard or failure mode becomes a node with the component and phenomenon as specified in the record. u Each row in the record becomes a link from the node that represents the cause to the node that represents the consequence. u The explanation column of the row forms the reason of the link. Seminar at Beijing University 24

Sept. 9, 2009 Example: Seminar at Beijing University 25 Sept. 9, 2009 Example: Seminar at Beijing University 25

Identification of Quality Concerns Ø For each node in the diagram Sept. 9, 2009 Identification of Quality Concerns Ø For each node in the diagram Sept. 9, 2009 u Identify the quality attribute or quality carrying property that the phenomenon demonstrates • Comparing the observable phenomenon with the definitions of a set of quality attributes and qualitycarrying properties • Recognising a new attribute or property, if no existing one matches. u Fill the identified quality attribute into the slot of the node Ø Examples, u ‘a hyperlink is broken’ demonstrates the quality attribute correctness of the HTML file. u ‘Server is down’ is related to the availability of the server. Seminar at Beijing University 26

Analysis of Graphic Quality Models ØContribution factors Sept. 9, 2009 What are the factors Analysis of Graphic Quality Models ØContribution factors Sept. 9, 2009 What are the factors that affect a specific quality issue that the user (designer) is interested in? Example: Factors of server’s responsiveness HTML files Well Structured Large size Server side - Load balance Some servers have high demand, but some not Need long time to transmit the files Seminar at Beijing University Server side - Performance Execution speed is slow Web Server - Responsiveness Long response time 27

ØImpacts of design decisions Sept. 9, 2009 What are the consequences of a design ØImpacts of design decisions Sept. 9, 2009 What are the consequences of a design decision? HTML files + Well Structured Large size Need long time to transmit the files HTML files + Navigability Small number of hyperlinks Web Server - Responsiveness Long response time Simpler hyperlink network usually easier to navigate Files are considered as unavailable when time-out System + Usability Easy to find required information Example: The impacts of HTML files are of large sizes Less nodes means less links System - Usability Cannot find required information Seminar at Beijing University 28

Ø Quality risks When a negative quality property is present, where does the risk Ø Quality risks When a negative quality property is present, where does the risk come from? And what are the implications of the problem? Sept. 9, 2009 HTML files + Well Structured Large size Server side - Load balance Some servers have high demand, but some not Server side - Performance Execution speed is slow Need long time to transmit the files Example: (partial model) The risk of long response time in a web-based application: its causes and implications System - Usability Cannot find required info Seminar at Beijing University Web Server - Responsiveness Long response time Files are considered as unavailable when time-out 29

ØRelationships between quality issues How two quality issues are interrelated? Sept. 9, 2009 Example: ØRelationships between quality issues How two quality issues are interrelated? Sept. 9, 2009 Example: Relationships between flexibility and performance Seminar at Beijing University 30

Sept. 9, 2009 ØTrade-off points: When a design decision has positive impact on one Sept. 9, 2009 ØTrade-off points: When a design decision has positive impact on one quality attribute but negative impact on another quality attribute, a trade-off must be made to balance between the two. Where are the points in a complicated design that need to make trade-offs? Or simply, where are the trade-off points? Example: EJB components’ size is a trade-off point in systems implemented using EJB. Seminar at Beijing University 31

Automation of Quality Analysis Ø SQUARE: Software QUality and ARchitecture modeling Environment. Tools to Automation of Quality Analysis Ø SQUARE: Software QUality and ARchitecture modeling Environment. Tools to support software architectural modelling Tools to support the derivation of software quality models from architectural design u Graph algorithms are designed and implemented to automate the analysis of software quality; Sept. 9, 2009 u u Project Manager Architecture Model Editor SA Model Repository Hazard Analysis Tools Quality Model Editor Quality Analysis Tools Quality Analysis Results Overall structure of SQUARE toolkits Seminar at Beijing University 32

Sept. 9, 2009 Screen Snapshot of SQUARE toolkits Seminar at Beijing University 33 Sept. 9, 2009 Screen Snapshot of SQUARE toolkits Seminar at Beijing University 33

Case Study Ø The subject: Sept. 9, 2009 u A real e-commerce system of Case Study Ø The subject: Sept. 9, 2009 u A real e-commerce system of online trading of medicine. u The system is operated by the local medicine trading regulation authority who supplies medicines to all stateowned hospitals in the province. u Its main functions: • customer relationship management, • product catalogue management, • online trade management, • online auction of medicine supplies, • online information advertisement, • a search engine for medicine information, and so on. u The system is implemented in J 2 EE u The system has been in operation for more than one year at the time of case study Seminar at Beijing University 34

Process of The Case Study Step 1: Construct the architectural model It is a Process of The Case Study Step 1: Construct the architectural model It is a reverse engineering process: Review of the design documents • The system’s design document consists of four main parts: (a) a simple and schematic J 2 EE architecture showing that the system uses J 2 EE as implementation technology; (b) interface design, which consists of a lot of HTML files; (c) database design, which consists of about 63 database tables; (d) a simple UML class diagram that contains a dozen of classes and shows the logical view of the system. u Review of parts of the source code. • When design information was not well documented, parts of the source code was reviewed u Construction of architectural model u Confirmation of architectural model by some of the chief developers of the system • The draft architectural model was reviewed and corrected • The final version of the model was approved of its accuracy Sept. 9, 2009 u Seminar at Beijing University 35

Sept. 9, 2009 Architecture of CRM Subsystem Seminar at Beijing University 36 Sept. 9, 2009 Architecture of CRM Subsystem Seminar at Beijing University 36

Sept. 9, 2009 Step 2: Construction of Quality Model Ø Employed the HASARD method Sept. 9, 2009 Step 2: Construction of Quality Model Ø Employed the HASARD method and the SQUARE toolkits Ø The quality model was reviews and corrected in several iterations with the collaboration with the developers Ø The final version was confirmed for its accuracy and correctness by the developers Ø The final result: 48 nodes u 60 links between the nodes. u Seminar at Beijing University 37

Step 3: Analysis of the Quality Model Ø The quality model was analysed using Step 3: Analysis of the Quality Model Ø The quality model was analysed using the SQUARE analysis tools of quality risks and quality trade-off points the impacts of design decision and the contribution factors on certain quality attributes Sept. 9, 2009 u Identification u Derivation of Ø The results were feed back to the developers u. A workshop was run to validate the outcomes • All our findings were consistent with what has been observed in the development and operation of the system. • Some of the phenomena observed in the operation of the system were first time satisfactorily explained u A number of specific suggestions on the improvement of the system’s architecture were made • Some were taken by the development team in the development of the new release of the system. • Some would result in major changes of system’s architecture and regrettably cannot be implemented within the budget of the new releases. Seminar at Beijing University 38

Example 1: Causes of usability problem Ø The quality problem concerned: u ‘Users often Example 1: Causes of usability problem Ø The quality problem concerned: u ‘Users often cannot find desired information on the website’ Ø Analysis goal: u Find the factors that may cause the problem Sept. 9, 2009 Ø Method: u Select the node that contains ‘user’ as the entity and “Cannot find info” as its phenomenon u Use the tool to find the contribution factors to this node Ø Result: u The tool generated a sub-diagram that contains 25 nodes out of the 48 nodes in the quality model. Ø Interpretation of the result: u Most components of the system affect usability of the system u Usability is a very sensitive quality issue in the design Ø The outcome: u Details are provided by the tool about u Useful direction to enhance usability Seminar at Beijing University what affect usability 39

Example 2: Contribution Factors to Server’s Availability ØProblem to be analysed: u What are Example 2: Contribution Factors to Server’s Availability ØProblem to be analysed: u What are the factors that affect the server’s availability? ØMethod: Sept. 9, 2009 u Select the node that contains ‘server’ as entity and ‘availability’ as property. u Use the tool to find the contribution factors. ØResult: u. A sub-diagram is generated, that shows that the factors include hardware reliability, software reliability, power supply, system security, and maintenance. ØOutcome: Suggested measures to improve availability u To u To prevent hackers from attacking the server ensure a reliable power supply use reliable hardware to run the server use fault tolerance to avoid software crashes on invalid input provide maintenance tools to enable online maintenance reduce the time that the system has to be shut down for maintenance Seminar at Beijing University 40

Sept. 9, 2009 Quality factors that affect server’s availability Seminar at Beijing University 41 Sept. 9, 2009 Quality factors that affect server’s availability Seminar at Beijing University 41

Example 3: Identify the quality trade-off points Ø Problem to be analysed: u What Example 3: Identify the quality trade-off points Ø Problem to be analysed: u What are the trade-off points in the design? Ø Method: Sept. 9, 2009 u u Select a node and to find the consequences of the node using the tool Identify whether is leads to both positive result and negative result Examples: • The size of HTML files is a trade-off point. (See diagram on slide 25) • The granularity of the session beans. Seminar at Beijing University 42

Comparison with related works Ø Scenario-based analysis of software architectures SAAM, ATAM, etc. : Comparison with related works Ø Scenario-based analysis of software architectures SAAM, ATAM, etc. : • Builds no quality model, • not automated u Our approach: • More systematic to derive quality model from design, • Can be automated for analysis once a model is constructed, • Models can be relatively easily validated Sept. 9, 2009 u Ø Hazard analysis of software system HAZOP, FMEA, etc. : • Focused on safety, • Systematic, • But not interrelationships between quality attributes u Our approach: • More general rather than just for safety, • Focuses on the relationships between attributes u Seminar at Beijing University 43

Future work Ø Combining with scenario-based methods construct graphic quality models u to represent Future work Ø Combining with scenario-based methods construct graphic quality models u to represent results of scenario analysis Sept. 9, 2009 u to Ø Analysis other quality features, e. g. u Process-oriented quality features: how does a design affect the software development process? Such as reusability, modifiability, portability, etc. Ø More case studies u Existing case study is on e-Commerce web-based applications u Work in progress: real-time and embedded systems Seminar at Beijing University 44

References Sept. 9, 2009 Ø Ø H. Zhu, Y. Zhang, Q. Huo and S. References Sept. 9, 2009 Ø Ø H. Zhu, Y. Zhang, Q. Huo and S. Greenwood, Application of Hazard Analysis to Software Quality Modelling, in Proc. of COMPSAC’ 02, pp. 139 -144, IEEE CS, 2002. H. Zhu, Software Design Methodology: From Principles to Architectural Styles, Elsevier, 2005. Q. Zhang, J. Wu, and H. Zhu, Tool Support to Modelbased Quality Analysis of Software Architectures, Proc. Of COMPSAC’ 06, IEEE CS, 2006. Q. Zhang and H. Zhu, Automated Analysis of Software Designs with Graphic Quality Models, WSEAS Transactions on Computers, Vol. 5, Issue 10, Oct. 2006, ISSN 1109 -2750, pp 2232 -2237. Seminar at Beijing University 45

Sept. 9, 2009 Acknowledgement The work reported in this talk is based on the Sept. 9, 2009 Acknowledgement The work reported in this talk is based on the research collaborated with Dr. Yanlong Zhang of Manchester Metropolitan University, UK, Dr. Sue Greenwood of Oxford Brookes University, UK, Ms. Qian Zhang and Mr. Jian Wu of National University of Defence Technology, China. Seminar at Beijing University 46