Lecture 6 HIGH-LEVEL DESIGN PB007  So(ware  Engineering  I   Faculty  of  Informa:cs,  Masaryk  University   Fall  2015   1  ©  Barbora  Bühnová   ©  Clear  View  Training  2010  v2.6   2   Purpose of system design ² Refine how the system's functions are to be implemented and how non-functional requirements are to be ensured ² Decide on strategic design issues such as concurrency, redundancy, persistence, distribution etc. to end with a design satisfying both functional and non-functional requirements ² Create policies to deal with tactical design issues Design best practices ² A system design consists of a collection of decisions that help to control different attributes of software quality. §  The design aims to ensure achievement of system functionality, but whenever there are different ways to achieve the functionality, the impact of each design decision on software quality becomes the issue. ² Quality-driven design decisions are often known as tactics, which isolate and describe design best practices with respect to a specific quality attribute. §  Design patterns are a specific and very popular tactic used during low-level design. 3  Chapter  7  Design  and  implementa:on   Outline ² Design for reliability and availability ² Design for security ² Design for performance, modifiability and usability ² UML Class Diagram in Design §  Design classes §  Design relationships 4  Chapter  7  Design  and  implementa:on   Design for Reliability and Availability Lecture  6/Part  1   5  Chapter  13  Dependability  Engineering   Software reliability and availability ² In general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures. ² Some applications (critical systems) have very high dependability requirements and special software engineering techniques may be used to achieve this. §  Medical systems §  Telecommunications and power systems §  Aerospace systems 6  Chapter  13  Dependability  Engineering   Dependability achievement ² Fault avoidance §  The development process is organised so that faults in the system are detected and repaired before delivery to the customer. §  Verification and validation techniques are used to discover and remove faults in a system before it is deployed. ² Fault detection §  Run-time techniques to detect faults and failures, such as acceptance tests, ping/echo, heartbeat. ² Fault tolerance §  The system is designed so that faults in the delivered software do not result in system failure. 7  Chapter  13  Dependability  Engineering   Dependable processes for fault avoidance ² To ensure a minimal number of software faults, it is important to have a well-defined, repeatable software process. ² The process should not depend entirely on individual skills; rather can be enacted by different people. ² QA engineers use information about the process to check if good software engineering practice has been used. ² It is clear that the process activities should include significant effort devoted to verification and validation. 8  Chapter  13  Dependability  Engineering   Static fault detection and its costs 9  Chapter  13  Dependability  Engineering   Dynamic fault detection tactics ² Monitoring and event processing. Collection, logging and processing events that may signal problems. ² Acceptance tests and exceptions. Acceptance checking for individual methods and code fragments, raising exception to trigger fault handling. ² Ping/echo. One component issues a ping and expects to receive back an echo, within a predefined time. ² Heartbeat (dead man timer). In this case one component emits a heartbeat message periodically and another component listens for it. If the heartbeat fails, the fault correction component is notified. 10   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Fault tolerance ² In critical situations, software systems must be fault tolerant. §  Fault tolerance is required where there are high availability requirements or where system failure costs are very high. ² Fault tolerance means that the system can continue in operation in spite of software failure. §  Even if the system has been proved to conform to its specification, it must also be fault tolerant as there may be specification errors or the validation may be incorrect. ² Dependable systems architectures are used in situations where fault tolerance is essential. §  These architectures are generally all based on redundancy and diversity. 11  Chapter  13  Dependability  Engineering   Diversity and redundancy ² Redundancy §  Keep more than 1 version of a critical component available so that if one fails then a backup is available. §  E.g. switch to backup servers automatically if failure occurs. ² Diversity §  Provide the same functionality in different ways so that they will not fail in the same way. §  E.g. different servers may be implemented using different operating systems (e.g. Windows and Linux). ² However, adding diversity and redundancy adds complexity and this can increase the chances of error. §  Some engineers advocate simplicity and extensive V & V is a more effective route to software dependability. 12  Chapter  13  Dependability  Engineering   Fault tolerance and recovery tactics (1) ² Exception handling §  Detection, signaling and propagation of the information about system faults, including the handling on an appropriate place. §  Decide well on the responsibilities in the system. ² Checkpoint/rollback §  Recording of a consistent state (either periodically or in response to specific events), to which the system can be restored. ² Recovery capabilities §  The system should be able to perform a clean-up after a major failure, so that no disturbances remain in the system. 13   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Fault tolerance and recovery tactics (2) ² Active redundancy (hot restart) §  All redundant components respond to events in parallel. Consequently, they are all in the same state. The response from only one component is used (usually the first to respond. ² Passive redundancy (warm restart/dual redundancy) §  One component (the primary) responds to events and informs the other components (the standbys) of state updates they must make. ² Voting §  Processes running on redundant processors each take equivalent input and compute a simple output value that is sent to a voter to choose non-deviant result. 14   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   N-version programming pattern ² Multiple versions of a software system carry out computations at the same time. §  The versions should be designed and implemented by different teams, to avoid repeating the same mistake. ² The results are compared using a voting system and the majority result is taken to be the correct result. Which of the tactics are involved here? Chapter  13  Dependability  Engineering   15   Protection systems ² A specialized monitoring and control system that is associated with another system, which can take emergency action if a failure occurs. §  System to stop a train if it passes a red light §  System to shut down a reactor if temperature is too high ² Protection systems are redundant because they include monitoring and control capabilities that replicate those in the controlled software. ² Protection systems should be diverse and use different technology from the controlled software. Chapter  13  Dependability  Engineering   16   Key points ² Reliability and availability achievement §  Fault avoidance, fault detection and fault tolerance ² Fault avoidance §  Repeatable software development process §  Testing ² Fault detection §  Monitoring, acceptance testing, ping/echo, heartbeat ² Fault tolerance §  Redundancy and diversity §  N-version programming Chapter  13  Dependability  Engineering   17   Design for Security Lecture  6/Part  2   Chapter  14  Security  Engineering   18   Design for security ² Two fundamental issues have to be considered when designing an architecture for security. §  Protection •  How should the system be organised so that critical assets can be protected against external attack? §  Distribution •  How should system assets be distributed so that the effects of a successful attack are minimized? ² These are potentially conflicting §  If assets are distributed, then they are more expensive to protect. If assets are protected, then usability and performance requirements may be compromised. Chapter  14  Security  Engineering   19   Protection ² Platform-level protection §  Top-level controls on the platform on which a system runs. ² Application-level protection §  Specific protection mechanisms built into the application itself e.g. additional password protection. ² Record-level protection §  Protection that is invoked when access to specific information is requested ² These lead to a layered protection architecture Chapter  14  Security  Engineering   20   A layered protection architecture Chapter  14  Security  Engineering   21   Distribution ² Distributing assets means that attacks on one system do not necessarily lead to complete loss of system service ² Each platform has separate protection features and may be different from other platforms so that they do not share a common vulnerability ² Distribution is particularly important if the risk of denial of service attacks is high Chapter  14  Security  Engineering   22   Security guidelines Security tactics Base security decisions on an explicit security policy Avoid a single point of failure Fail securely Balance security and usability Log user actions Use redundancy and diversity to reduce risk Compartmentalize your assets Design for recoverability Design for deployment Validate all inputs Chapter  14  Security  Engineering   23   Security guidelines 1-3 ² Base decisions on an explicit security policy §  Define a security policy for the organization that sets out the fundamental security requirements that should apply to all organizational systems. ² Avoid a single point of failure §  Ensure that a security failure can only result when there is more than one failure in security procedures. For example, have password and question-based authentication. ² Fail securely §  When systems fail, for whatever reason, ensure that sensitive information cannot be accessed by unauthorized users even although normal security procedures are unavailable. Chapter  14  Security  Engineering   24   Security guidelines 4-6 ² Balance security and usability §  Try to avoid security procedures that make the system difficult to use. Sometimes you have to accept weaker security to make the system more usable. ² Log user actions §  Maintain a log of user actions that can be analyzed to discover who did what. If users know about such a log, they are less likely to behave in an irresponsible way. ² Use redundancy and diversity to reduce risk §  Keep multiple copies of data and use diverse infrastructure so that an infrastructure vulnerability cannot be the single point of failure. Chapter  14  Security  Engineering   25   Security guidelines 7-10 ² Compartmentalize your assets §  Organize the system so that assets are in separate areas and users only have access to the information that they need rather than all system information. ² Design for recoverability §  Design the system to simplify recoverability after a successful attack. ² Design for deployment §  Design the system to avoid deployment problems ² Validate all inputs §  Check that all inputs are within range so that unexpected inputs cannot cause problems. Chapter  14  Security  Engineering   26   System survivability ² Survivability = system ability to deliver essential services whilst it is under attack or after part of it was damaged. ² Resistance §  Avoiding problems by building capabilities into the system to resist attacks ² Recognition §  Detecting problems by building capabilities into the system to detect attacks and failures and assess the resultant damage ² Recovery §  Tolerating problems by building capabilities into the system to deliver services whilst under attack Chapter  14  Security  Engineering   27   Key points ² Design for security involves §  Protection §  Distribution ² Layered protection architecture §  Platform-level protection §  Application-level protection §  Record-level protection ² Security guidelines ² Survivability Chapter  14  Security  Engineering   28   Design for Performance, Modifiability and Usability Lecture  6/Part  3   29   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Performance tactics ² Introduce concurrency. If requests can be processed in parallel, the blocked time can be reduced. But it is necessary to understand well the concurrency effects. ² Control the use of resources. This includes both computational resources and data. Namely, balance the load, control access, scheduling (via priority), cache, maintain multiple copies to reduce contention. ² Increase available resources. Faster processors, additional processors, additional memory, and faster networks all have the potential for reducing latency. What is the role of vertical and horizontal scalability here? 30   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Modifiability tactics – Defer binding time ² Runtime registration supports plug-and-play operation at the cost of additional overhead to manage the registration. Publish/subscribe registration, for example, can be implemented at either runtime or load time. ² Configuration files are intended to set parameters at startup. ² Polymorphism allows late binding of method calls. ² Component replacement allows load time binding. ² Adherence to defined protocols allows runtime binding of independent processes. 31   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Modifiability tactics – Prevent ripple effects ² A ripple effect from a modification is the necessity of making changes to modules not directly affected by it. §  For instance, if module A is changed to accomplish a particular modification, then module B is changed only because of the change to module A. B has to be modified because it depends, in some sense, on A. ² Hide information. Information hiding is the decomposition of the responsibilities for an entity (a system or some decomposition of a system) into smaller pieces and choosing which information to make visible. 32   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Usability tactics – Design-time tactics ² Separate the user interface from the rest of the application. Localizing expected changes is the rationale for semantic coherence. ² Since the user interface is expected to change frequently both during the development and after deployment, maintaining the user interface code separately will localize changes to it. 33   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Usability tactics – Runtime tactics ²  Maintain a model of the task. The task model is used to determine context so the system can have some idea of what the user is attempting and provide various kinds of assistance. §  For example, knowing that sentences usually start with capital letters would allow an application to correct a lower-case letter in that position. ²  Maintain a model of the user. The model determines the user's knowledge of the system, the user's behavior in terms of expected response time, and other aspects specific to a user or a class of users. §  For example, maintaining a user model allows the system to pace scrolling so that pages do not fly past faster than they can be read. ²  Maintain a model of the system. The model determines the expected system behavior so that appropriate feedback can be given to the user. 34   ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   Quality conflicts ² Within complex systems, quality attributes can never be achieved in isolation. §  The achievement of any one will have an effect, sometimes positive and sometimes negative, on the achievement of others. ² For example, almost every quality attribute negatively affects performance. §  Reliability. Redundancy together with a voting schema delays system response. §  Portability. The main technique for achieving portable software is to isolate system dependencies, which introduces overhead into the system's execution. ©  So(ware  Architecture  in  Prac:ce     by  L.  Bass,  P.  Clements  and  R.  Kazman   35   Quality conflicts ²  It is not possible for any system to be optimized for all of these attributes. ²  The quality plan should therefore define the most important quality attributes for the software that is being developed. 36  ©  Bára  Bühnová   UML Class Diagram in Design Lecture  6/Part  4   37  ©  Clear  View  Training  2010  v2.6   ©  Clear  View  Training  2010  v2.6   38   Design model ² Design model is a refinement of an analysis model to such a degree that it can be implemented §  In MDD design models include all implementation details and can be automatically translated into code ² In OO design models: §  All attributes are completely specified §  Analysis operations become fully specified methods §  Many new classes are added to include implementation details, such as utility classes (String, Date, Time, etc.), middleware classes (DB access, communication, etc.) or GUI classes (Applet, Button, etc.) ² Design models are programming-language specific §  Multiple inheritance, templates, nested classes, collections ©  Clear  View  Training  2010  v2.6   39   ² A design model may contain 10 to 100 times as many classes as the analysis model §  The analysis model helps us to see the big picture without getting lost in implementation details ² We need to maintain both models if: §  It is a big system ( >200 design classes) §  It has a long expected lifespan §  It is a strategic system §  We are outsourcing construction of the system ² Otherwise, we can make it with only a design model Analysis vs. design model ©  Clear  View  Training  2010  v2.6   40   Anatomy of a design class ²  A design class shall have: §  A complete set of operations including parameter lists, return types, visibility, exceptions, set and get operations, constructors §  A complete set of attributes including types and default values BankAccount -name:String -number:String -balance:double = 0 +BankAccount(name:String, number:String) +deposit(m:double):void +withdraw(m:double):boolean +calculateInterest():double +getName():String +setName(n:String):void +getAddress():String +setAddress(a:String):void +getBalance():double BankAccount name number balance deposit() withdraw() calculateInterest() analysis design «trace» constructor ©  Clear  View  Training  2010  v2.6   41   High cohesion, low coupling ²  High cohesion §  Each class should have a set of operations that support the intent of the class, no more and no less §  Each class should model a single abstract concept ²  Low coupling §  A particular class should be associated with just enough other classes to allow it to realise its responsibilities §  Only associate classes if there is a true semantic link between them – never to only reuse code! §  Use aggregation rather than inheritance ²  Primitive operations §  Each operation shall implement a single functionality, and each functionality shall be implemented by single operation Employee Manager Programmer john:Programmer «instantiate» What is wrong with this model? ©  Clear  View  Training  2010  v2.6   42   Aggregation vs. inheritance ²  An employee has a job, not is a job. ²  An employee can have more jobs. just change this link at runtime to promote john! Job Manager Programmer john:Employee Employee :Programmer «instantiate» :Manager «instantiate» «instantiate» 0..*0..* Employee Manager Programmer john:Programmer «instantiate» ©  Clear  View  Training  2010  v2.6   43   ² With inheritance we get two things: §  Interface – the public operations of the base classes §  Implementation – the attributes, relationships, operations of the class ² With interface we get one thing: §  Interface – a set of public operations, attributes and relationships that have no implementation Use interface realization when we want to define a contract. Inheritance vs. interface realization Job Manager Programmer Job Manager Programmer Use inheritance when we want to inherit implementation. ©  Clear  View  Training  2010  v2.6   44   Key points (design classes) ² Design classes come from: §  A refinement of analysis classes (i.e. the business domain) §  From the solution domain ² Design classes must be well-formed: §  High cohesion §  Low coupling §  Primitive operations ² Don’t overuse inheritance §  Use inheritance for "is kind of" §  Use aggregation for "is role played by" §  Use interfaces rather than inheritance to define contracts ©  Clear  View  Training  2010  v2.6   45   Design relationships ² Refining analysis associations to design associations involves several procedures: §  refining associations to aggregation or composition §  implementing one-to-many associations §  implementing many-to-one associations §  implementing many-to-many associations §  implementing bidirectional associations §  implementing association classes ² All design associations must have: §  navigability §  multiplicity on both ends ©  Clear  View  Training  2010  v2.6   46   Aggregation and composition A B A B A B «trace» «trace» {xor} AnalysisDesign aggregation composition Some objects are strongly related like a tree and its leaves Some objects are weakly related like a computer and its peripherals ©  Clear  View  Training  2010  v2.6   47   Aggregation semantics n  The aggregate can (sometimes) exist independently of the parts n  The parts can (sometimes) exist independently of the aggregate n  It is possible to have shared ownership of the parts by several aggregates Computer Printer 0..* 0..* whole or aggregate part aggregation is a whole–part relationship A Computer may be attached to 0 or more Printers At any one point in time a Printer is connected to 0 or more Computers The Printer exists even if there are no Computers The Printer is independent of the Computer aggregation ©  Clear  View  Training  2010  v2.6   48   Composition semantics ²  The parts belong to exactly 1 whole at a time ²  The composite has sole responsibility for the disposition of all its parts. This means responsibility for their creation and destruction ²  If the composite is destroyed, it must either destroy all its parts, OR give responsibility for them over to some other object (the exception above) Mouse Button 1 1..4 composition is a strong form of aggregation composite part composition always 1 (with an exception of a transferable part, when it is 0) The buttons have no independent existence. If we destroy the mouse, we destroy the buttons. They are an integral part of the mouse Each button can belong to exactly 1 mouse ©  Clear  View  Training  2010  v2.6   49   •  Many-­‐to-­‐one  rela:onships  in     analysis  imply  shared  ownership   and  are  refined  to  aggrega:ons   •  One-­‐to-­‐one  associa:ons  in  analysis   usually  imply  single  ownership  and   usually  refine  to  composi:ons   A B 1 1 A B 1 1 «trace» roleName One to one A B 0..* 1 A B 0..* 1 «trace» roleName Many to one analysis design One-to-one and many-to-one associations ©  Clear  View  Training  2010  v2.6   50   One-to-many and many-to-many associations ²  Collection classes instances store a collection of object references to objects of the target and provide methods for operating the collection ²  In Java in the java.util library A B 1 0..* A B 1 0..* Vector 1 1 «trace» Many to manyOne to many Task Resource 0..* 0..* AllocationTask Resource 10..*1 0..* «trace» ²  Many-to-many associations may be (but do not have to be) refined into intermediate design classes. ©  Clear  View  Training  2010  v2.6   51   Bi-directional associations ²  There is no commonly used OO language that directly supports bidirectional associations ²  We must resolve each bi-directional associations into two unidirectional associations ²  Again, we must decide which side of the association should have primacy and use composition, aggregation and navigability accordingly A B1 0..* A B 1 0..* 1 0..* «trace» this side has primacy ©  Clear  View  Training  2010  v2.6   52   Association classes ²  There is no commonly used OO language that directly supports association classes ²  Refine all association classes into a design class ²  Decide which side of the association has primacy and use composition, aggregation and navigability accordingly Company Person 0..* 0..* Job salary:double Company Person Job salary:double 0..*0..* 11 «trace» {each Person can only have one job with a given Company} this side has primacy ©  Clear  View  Training  2010  v2.6   53   Key points (design relationships) ²  In this section we have seen how we take the incompletely specified associations in an analysis model and refine them to: §  Aggregation •  Whole-part relationship •  Parts are independent of the whole •  Parts may be shared between wholes §  Composition •  A strong form of aggregation •  Parts are entirely dependent on the whole •  Parts may not be shared ²  One-to-many, many-to-many, bi-directional associations and association classes are refined in design