Lecture 8 ARCHITECTURE DESIGN PB007  So(ware  Engineering  I   Faculty  of  Informa:cs,  Masaryk  University   Fall  2015   1  ©  Barbora  Bühnová   Topics covered ² Architecture design ² UML Packages (Analysis) ² UML Component Diagram (Design) ² UML Deployment Diagram (Realisation) 2  Chapter  6  Architectural  design   Architecture Design Lecture  8/Part  1   3  Chapter  6  Architectural  design   Topics covered ² Architectural views ² Architectural design decisions ² Architectural patterns ² Application architectures 4  Chapter  6  Architectural  design   Architectural abstraction ² Architecture in the small (analysis) is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components. ² Architecture in the large (design) is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies. 5  Chapter  6  Architectural  design   4 + 1 view model of software architecture 6  Chapter  6  Architectural  design   Logical  view  shows  the  key   abstrac:ons  in  the  system  as   objects  or  object  classes.                      Physical  view  shows     system  hardware  and     how  so(ware  components     are  distributed  across  system   processors.   Process  view  shows  how,  at   run-­‐:me,  the  system  is   composed  of  interac:ng   processes.     Use  cases  and     scenarios  view   Development  view     shows  how  the  so(ware     is  decomposed  for   development.   Architectural design decisions ² Architectural design is a creative process so the process differs depending on the type of system being developed. ² However, a number of common decisions span all design processes and these decisions affect the non-functional characteristics of the system. 7  Chapter  6  Architectural  design   Architectural design decisions ² How will the system be decomposed into modules? ² What approach will be used to structure the system? ² What architectural styles are appropriate? ² What control strategy should be used? ² Is there a generic application architecture that can be used? ² How should the architecture be documented? ² How will the system be distributed? ² How will the architectural design be evaluated? 8  Chapter  6  Architectural  design   Architecture and system characteristics ² Performance §  Localise critical operations and minimise communications. Use large rather than fine-grain components. ² Security §  Use a layered architecture with critical assets in the inner layers. ² Safety §  Localise safety-critical features in a small number of components. ² Reliability and Availability §  Include redundant components and mechanisms for fault tolerance. ² Maintainability §  Use fine-grain, replaceable components. 9  Chapter  6  Architectural  design   Architectural patterns ² Patterns are a means of representing, sharing and reusing knowledge. ² An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. ² Patterns should include information about when they are and when the are not useful. ² Patterns may be represented using tabular and graphical descriptions. 10  Chapter  6  Architectural  design   The Model-View-Controller (MVC) pattern 11  Chapter  6  Architectural  design   ² Separates presentation and interaction from the system data. The Model-View-Controller (MVC) pattern Name MVC (Model-View-Controller) Description Separates presentation and interaction from the system data. The system is structured into three logical components that interact with each other. The Model component manages the system data and associated operations on that data. The View component defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. Example Figure on the next slide shows the architecture of a web-based application system organized using the MVC pattern. When used Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Advantages Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways with changes made in one representation shown in all of them. Disadvantages Can involve additional code and code complexity when the data model and interactions are simple. 12  Chapter  6  Architectural  design   Web application architecture using MVC 13  Chapter  6  Architectural  design   The Layered architecture pattern ² Organises the system into a set of layers with interfaces to other layers. Supports incremental development. 14  Chapter  6  Architectural  design   The Layered architecture pattern Name Layered architecture Description Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system. Example A layered model of a system for sharing copyright documents held in different libraries. When used Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Advantages Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability of the system. Disadvantages In practice, providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer. 15  Chapter  6  Architectural  design   The architecture of the LIBSYS system 16  Chapter  6  Architectural  design   The Repository architecture pattern ² When large amounts of data are to be shared among subsystems, the repository model offers a solution. 17  Chapter  6  Architectural  design   The Repository architecture pattern Name Repository Description All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. Example Figure on the previous slide is an example of an IDE where the components use a repository of system design information. Each software tool generates information which is then available for use by other tools. When used You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool. Advantages Components can be independent—they do not need to know of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., backups done at the same time) as it is all in one place. Disadvantages The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult. 18  Chapter  6  Architectural  design   The Client-server architecture pattern ² Distribution of data and processing across stand-alone service-providing servers and clients calling the services. 19  Chapter  6  Architectural  design   The Client–server pattern Name Client-server Description In a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them. Example Figure on the previous slide is an example of a film and video/DVD library organized as a client–server system. When used Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable. Advantages The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) can be available to all clients and does not need to be implemented by all services. Disadvantages Each service is a single point of failure so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations. 20  Chapter  6  Architectural  design   The Pipe and filter architecture pattern ² Functional transformations process their inputs to produce outputs. ² Variants of this approach are very common. When transformations are sequential, this is known as batch sequential model used in data processing systems. 21  Chapter  6  Architectural  design   The Pipe and filter pattern Name Pipe and filter Description The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing. Example Figure on the previous slide is an example of a pipe and filter system used for processing invoices. When used Commonly used in data processing applications (both batch- and transaction-based) where inputs are processed in separate stages to generate related outputs. Advantages Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system. Disadvantages The format for data transfer has to be agreed upon between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse functional transformations that use incompatible data structures. 22  Chapter  6  Architectural  design   Application architectures ² Application systems are designed to meet an organisational need. ² As businesses have much in common, their application systems also tend to have a common architecture that reflects the application requirements. ² A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements. 23  Chapter  6  Architectural  design   Examples of application types ² Data processing applications §  Data driven applications that process data in batches without explicit user intervention during the processing. ² Transaction processing applications §  Data-centred applications that process user requests and update information in a system database. ² Event processing systems §  Applications where system actions depend on interpreting events from the system’s environment. ² Language processing systems §  Applications where the users’ intentions are specified in a formal language that is processed and interpreted by the system. Chapter  6  Architectural  design   24   The architecture of a transaction processing application (ATM system) – a process view 25  Chapter  6  Architectural  design   Layered architecture of a transaction processing application (Information system) 26  Chapter  6  Architectural  design   Pipe and filter architecture of a language processing system (Compiler) 27  Chapter  6  Architectural  design   Repository architecture of a language processing system 28  Chapter  6  Architectural  design   Key points ² A software architecture is a description of how a software system is organized. ² Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used. ² Architectural patterns are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages. ² Application systems architectures embody a common architecture that the businesses have in common. Chapter  6  Architectural  design   29   ©  Clear  View  Training  2010  v2.6   30   UML Packages (Analysis) Lecture  8/Part  2   ©  Clear  View  Training  2010  v2.6   31   Packages ² A package is a general purpose mechanism for organising model elements into groups §  Group semantically related elements §  Define a “semantic boundary” in the model §  Provide units for parallel working and configuration management ² In UML 2 a package is a purely logical grouping mechanism §  Use components for physical grouping ² Analysis packages contain: §  Analysis classes, analysis packages, use cases, use case realizations. ©  Clear  View  Training  2010  v2.6   32   Package syntax Membership   +ClubMembership   +Benefits   +MembershipRules   +MemberDetails:Member   -­‐JoiningRules     Membership   Membership:MemberDetails   Membership   ClubMembership   MembershipRules   Benefits  JoiningRules   MemberDetails   Member   «access»   public   (exported)   elements   private   element   qualified   package     name   accessed  from   another  package   •  Use  stereotypes  to  dis:nguish  different  package  purposes.   ©  Clear  View  Training  2010  v2.6   33   Nested packages n  Each  package  defines  an   encapsulated  namespace  i.e.   all  names  must  be  unique   within  the  package     n  If  an  element  is  visible  within   a  package  then  it  is  visible   within  all  nested  packages     n  e.g.  Benefits  is  visible   within  MemberDetails   n  Show  containment  using   nes:ng  or  the  containment   rela:onship   n  Use  «access»  or  «import»  to   merge  the  namespace  of   nested  packages  with  the   parent  namespace       Membership   ClubMembership   MembershipRules   Benefits   JoiningRules   MemberDetails   Member   «import»   containment  rela:onship   anchor  icon   Membership   ClubMembership   MembershipRules   Benefits  JoiningRules   MemberDetails   Member   «import»   ©  Clear  View  Training  2010  v2.6   34   Package dependencies Supplier   «use»   Client   Supplier   «import»   Client   Supplier   «access»   Client   Public  elements  of  the  supplier  namespace  are  added  as  private   elements  to  the  client  namespace.  Not  transi9ve.   Public  elements  of  the  supplier  namespace  are  added  as  public   elements  to  the  client  namespace.  Transi9ve.   An  element  in  the  client  uses  an  element  in  the  supplier  in   some  way.  The  client  depends  on  the  supplier.  Transi9ve.   «trace»  usually  represents  a  historical  development  of  one   element  into  another  more  refined  version.  It  is  an  extra-­‐model   rela:onship.  Transi9ve.   Analysis   Model   «trace»   Design   Model   dependency   seman:cs   C   B   A   transi:vity  -­‐  if  dependencies  x  and  y  are  transi:ve,   there  is  an  implicit  dependency  between  A  and  C   y   x   ©  Clear  View  Training  2010  v2.6   35   Package generalisation ² The more specialised child packages inherit the public and protected elements in their parent package ² Child packages may override elements in the parent package. Both Hotels and CarHire packages override Product::Item ² Child packages may add new elements. Hotels adds Hotel and RoomType, CarHire adds Car +Price   +Market   +Item   -­‐MicroMarket   Product   +Product::Price   +Product::Market   +Item   +Hotel   +RoomType   Hotels   +Product::Price   +Product::Market   +Item   +Car   CarHire   children   parent   ©  Clear  View  Training  2010  v2.6   36   Architectural analysis ² This involves organising the analysis classes into a set of cohesive packages §  The architecture should be partitioned to separate concerns, such as to specific and application general layers §  Coupling between packages should be minimised Products   Inventory   Management   Sales   Account   Management   applica:on   specific  layer   applica:on   general  layer   par::ons   ©  Clear  View  Training  2010  v2.6   37   Finding analysis packages ²  A cohesive group of closely related classes or a class hierarchy ²  4 to 10 classes per package ²  Minimise dependencies between packages ²  Localise business processes in packages where possible ²  Minimise nesting of packages ²  Don’t worry about dependency stereotypes and package generalisation ²  Refine package structure as analysis progresses ²  Avoid cyclic dependencies! A   merge   split  A   B   A   B   C   ©  Clear  View  Training  2010  v2.6   38   Key points ² Packages are the UML way of grouping modeling elements ² There are dependency and generalisation relationships between packages ² The package structure of the analysis model defines the logical system architecture ©  Clear  View  Training  2010  v2.6   39   UML Component Diagram (Design) Lecture  8/Part  3   ©  Clear  View  Training  2010  v2.6   40   Example of a (layered) architecture «subsystem»   GUI   «subsystem»   Customer   «subsystem»   Order   «subsystem»   Product   «subsystem»   Accounts   «subsystem»   java.sql   «subsystem»   {global}   java.u:l   «subsystem»   javax.swing   Customer   Manager   Product   Manager   OrderManager   Account   Manager   presenta:on   business     logic   u:lity   ©  Clear  View  Training  2010  v2.6   41   What is a component? ² The UML 2.0 specification states that, "A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment" §  A black-box whose external behaviour is completely defined by its provided and required interfaces §  May be substituted for by other components provided they all support the same protocol ² Components can be: §  Physical – can be directly instantiated at run-time e.g. an Enterprise JavaBean (EJB) §  Logical – a purely logical construct e.g. a subsystem ©  Clear  View  Training  2010  v2.6   42   «delegate»   Component syntax ² Components may have provided and required interfaces, ports, internal structure §  Provided and required interfaces usually delegate to internal parts §  You can show the parts nested inside the component icon or externally, connected to it by dependency relationships «component»   A  I1   I2   provided     interface   required     interface   component   «component»   A   B   C   I1   I2   I2   part   «delegate»   black  box  nota:on   white  box  nota:on   I1   ©  Clear  View  Training  2010  v2.6   43   Provided interface syntax ² A provided interface indicates that a classifier implements the services defined in an interface CD  Book   Borrow   «interface»   Borrow   borrow()   return()   isOverdue()   CD  Book   “Lollipop”  style  nota:on   (note:  you  can’t  show  interface   opera:ons  or  anributes  with  this   nota:on)   “Class”  style  nota:on   interface   realiza:on   rela:onship   ©  Clear  View  Training  2010  v2.6   44   Required interface syntax ² A required interface indicates that a classifier uses the services defined by the interface Borrow   Library   required  interface   Borrow   Library   «interface»   Borrow   Library   class  style  nota:on   lollipop  style  nota:on   ©  Clear  View  Training  2010  v2.6   45   Assembly connectors ² You can connect provided and required interfaces using an assembly connector Borrow   Book   CD   Library   1   1   0..*   0..*   assembly   connector   ©  Clear  View  Training  2010  v2.6   46   Ports for organizing interfaces ² A port specifies an interaction point between a classifier and its environment ² A port may have a name and is typed by its provided and required interfaces: §  It is a semantically cohesive set of provided and required interfaces DisplayMedium   Print,  Display   Book   presenta:on   port   Viewer   Book   presenta:on   ©  Clear  View  Training  2010  v2.6   47   Using interfaces ² Advantages: §  When we design with classes, we are designing to specific implementations §  When we design with interfaces, we are instead designing to contracts which may be realised by many different implementations (classes) §  Designing to contracts frees our model from implementation dependencies and thereby increases its flexibility and extensibility ² Disadvantages: §  Flexibility may lead to complexity §  Too many interfaces can make a system too flexible! §  Too many interfaces can make a system hard to understand ©  Clear  View  Training  2010  v2.6   48   Key points ² Interfaces specify a named set of public features: §  They define a contract that classes and subsystems may realise §  Programming to interfaces rather than to classes reduces dependencies between the classes and subsystems in our model §  Programming to interfaces increases flexibility and extensibility ² Design subsystems and interfaces allow us to: §  Componentize our system §  Define an architecture ©  Clear  View  Training  2010  v2.6   49   UML Deployment Diagram (Realisation) Lecture  8/Part  4   ©  Clear  View  Training  2010  v2.6   50   Deployment model ²  The deployment model models system’s physical architecture and the mapping of the software architecture to the physical nodes §  Each node is a type of computational resource §  Nodes have relationships that represent methods of communication §  Artifacts represent physical software e.g. a JAR file or .exe file «device»   WindowsPC   «execu:on  environment»   IE6   «device»   LinuxPC   «execu:on  environment»   Apache   0..*   0..*  «hnp»   node   associa:on   Descriptor   form  model   ©  Clear  View  Training  2010  v2.6   51   Instance form model ² A node instance represents an actual physical resource §  e.g. JimsPC:WindowsPC - node instances have underlined names «device»   JimsPC:WindowsPC   «execu:on  environment»   :IE6   «device»   WebServer1:LinuxPC   «execu:on  environment»   :Apache   node  instance   «device»   IlasPC:WindowsPC   «execu:on  environment»   :IE6   «hnp»   Instance     form  model   ©  Clear  View  Training  2010  v2.6   52   1   1   Artifacts and components ² Artifacts and components represent the software deployed on physical nodes ² An artifacts represents a concrete deployed real-world thing, such as a file §  Artifacts = Physical level ² Artifacts provide the physical manifestation for one or more components §  Components = Logical level «component»  Library   «component»  Book   «ar:fact»  librarySystem.jar   «manifest»   «manifest»   «component»  Ticket   «manifest»   BookImpl   ISBN   1   LibraryImpl   TicketImpl   TicketID   1   Book   Library   Ticket   «ar:fact»  jdom.jar   depends   ©  Clear  View  Training  2010  v2.6   53   Example ²  Artifacts are deployed on nodes, artifact instances are deployed on node instances deployment  descriptor   ar:fact  instance   «device»   client:WindowsPC   «device»  server:WindowsPC   «execu:on  environment»   :J2EE  Server   «RMI»   «JAR»   :ConverterApp.ear   «JAR»   :ConverterClient.jar   «deployment  spec»  converterDeploymentSpecifica:on   EnterpriseBeanClass:  ConverterBean   EnterpriseBeanName:  ConverterBean   EnterpriseBeanType:  StatelessSession   ©  Clear  View  Training  2010  v2.6   54   Key points ² The descriptor form deployment diagram §  Allows you to show how functionality represented by artifacts is distributed across nodes §  Nodes represent types of physical hardware or execution environments ² The instance form deployment diagram §  Allows you to show how functionality represented by artifact instances is distributed across node instances §  Node instances represent actual physical hardware or execution environments