Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Software Engineering Software Architecture N.L. Hsueh 1N.L. Hsueh, SE-Lab IECS FCU
  2. 2. Software Engineering Outline  Basic Concept  Architecture Styles  Control models  Modular decomposition  Domain-specific architectures  Design Pattern 2N.L. Hsueh, SE-Lab IECS FCU
  3. 3. Software Engineering Basic Concept  The architecture of a system is a comprehensive framework that describes its form and structure – its components and how they fit together  A bad architectural design for a building cannot be rescued by good construction; the same is true for software  There are styles of building and software architecture 3N.L. Hsueh, SE-Lab IECS FCU
  4. 4. Software Engineering Architectural design process  System structuring  The system is decomposed into several principal sub- systems and communications between these sub- systems are identified  Control modelling  A model of the control relationships between the different parts of the system is established  Modular decomposition  The identified sub-systems are decomposed into modules 4N.L. Hsueh, SE-Lab IECS FCU
  5. 5. Software Engineering Sub-systems and modules  A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.  A module is a system component that provides services to other components but would not normally be considered as a separate system 5N.L. Hsueh, SE-Lab IECS FCU
  6. 6. Software Engineering Architectural models  Structure, control and modular decomposition may be based on a particular model or architectural style  However, most systems are heterogeneous in that different parts of the system are based on different models and, in some cases, the system may follow a composite model  The architectural model used affects the performance, robustness, distributability and maintainability of the system 6N.L. Hsueh, SE-Lab IECS FCU
  7. 7. Software Engineering System structuring  Concerned with decomposing the system into interacting sub-systems  The architectural design is normally expressed as a block diagram presenting an overview of the system structure  More specific models showing how sub-systems share data, are distributed and interface with each other may also be developed 7N.L. Hsueh, SE-Lab IECS FCU
  8. 8. Software Engineering Architectural Style 8N.L. Hsueh, SE-Lab IECS FCU
  9. 9. Software Engineering 1. Main Program With Subroutines 9N.L. Hsueh, SE-Lab IECS FCU
  10. 10. Software Engineering Control Input Shift Sort Output store shifts sorted input output Procedure call Access to data structure i/o 10N.L. Hsueh, SE-Lab IECS FCU
  11. 11. Software Engineering 2. Abstract Data Type Control Input Output Store Shift Sort output output 11N.L. Hsueh, SE-Lab IECS FCU
  12. 12. Software Engineering  Store  initialStore:  PutChar(r,w,c,d):  CloseStore: it is called after all inputlines have been stored through successive calls of PutChar() Lines(): delivers the number of lines stores  Words(r)  Chars(r,w)  Char(r,w,c)  Input  Call Store.initialStore()  Read from input and call PutChar(…)  Call CloseStore() 12N.L. Hsueh, SE-Lab IECS FCU
  13. 13. Software Engineering  Shift ShiftLines()   ShiftWords(l)  ShiftChars(l,w)  ShiftChar(l,w,c)  Sort  iniSort  getIndex(w) 13N.L. Hsueh, SE-Lab IECS FCU
  14. 14. Software Engineering 3. Implicit Invocation Control Input MakeShift Sort Output input Store Shift output Implicit call The MakeShift module is no explicitly called 14N.L. Hsueh, SE-Lab IECS FCU
  15. 15. Software Engineering 4. Pipe and Filter Input Shift Sort Output input output 15N.L. Hsueh, SE-Lab IECS FCU
  16. 16. Software Engineering 5. Repository  Sub-systems must exchange data. This may be done in two ways:  Shared data is held in a central database or repository and may be accessed by all sub-systems  Each sub-system maintains its own database and passes data explicitly to other sub-systems  When large amounts of data are to be shared, the repository model of sharing is most commonly used 16N.L. Hsueh, SE-Lab IECS FCU
  17. 17. Software Engineering Conti. 17N.L. Hsueh, SE-Lab IECS FCU
  18. 18. Software Engineering Conti.  Advantages  Efficient way to share large amounts of data  Sub-systems need not be concerned with how data is produced  Centralized management e.g. backup, security, etc.  Sharing model is published as the repository schema  Disadvantages  Sub-systems must agree on a repository data model. Inevitably a compromise  Data evolution is difficult and expensive 18N.L. Hsueh, SE-Lab IECS FCU
  19. 19. Software Engineering 6. Layered 19N.L. Hsueh, SE-Lab IECS FCU
  20. 20. Software Engineering 7. Client-server  Distributed system model which shows how data and processing is distributed across a range of components  Set of stand-alone servers which provide specific services such as printing, data management, etc.  Set of clients which call on these services  Network which allows clients to access servers 20N.L. Hsueh, SE-Lab IECS FCU
  21. 21. Software Engineering Conti.  Advantages  Distribution of data is straightforward  Makes effective use of networked systems  Easy to add new servers or upgrade existing servers  Disadvantages  No shared data model so sub-systems use different data organization.  Data interchange may be inefficient  No central register of names and services - it may be hard to find out what servers and services are available 21N.L. Hsueh, SE-Lab IECS FCU
  22. 22. Software Engineering Control Model 22N.L. Hsueh, SE-Lab IECS FCU
  23. 23. Software Engineering Control models  Are concerned with the control flow between sub- systems.  Distinct from the system decomposition model  Centralized control  One sub-system has overall responsibility for control and starts and stops other sub-systems  Event-based control  Each sub-system can respond to externally generated events from other sub-systems or the system’s environment 23N.L. Hsueh, SE-Lab IECS FCU
  24. 24. Software Engineering 1. Centralized control  A control sub-system takes responsibility for managing the execution of other sub-systems  Call-return model  Top-down subroutine model  Control starts at the top of a subroutine hierarchy and moves downwards.  Applicable to sequential systems  Manager model  One system component controls the stopping, starting and coordination of other system processes.  Applicable to concurrent systems. 24N.L. Hsueh, SE-Lab IECS FCU
  25. 25. Software Engineering Call-return model M ain program Routine 1 Routine 2 Routine 3 Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2 25N.L. Hsueh, SE-Lab IECS FCU
  26. 26. Software Engineering A centralized control model for a real-time system control Sensor Actuator processes processes System controller Computation User Fault processes interface handler 26N.L. Hsueh, SE-Lab IECS FCU
  27. 27. Software Engineering 2. Event-driven systems  Driven by externally generated events where the timing of the event is outside the control of the sub-systems which process the event  In centralized control models, control decisions are usually determined by the value of some system state variables  Two principal event-driven models  Broadcast models. An event is broadcast to all sub- systems. Any sub-system which can handle the event may do so  Interrupt-driven models. Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component for processing 27N.L. Hsueh, SE-Lab IECS FCU
  28. 28. Software Engineering Broadcast model  Effective in integrating sub-systems on different computers in a network  Sub-systems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event  Control policy is not embedded in the event and message handler. Sub-systems decide on events of interest to them  However, sub-systems don’t know when an event will be handled Sub-system K Sub-system K m1.registerTo(m2) m1.registerTo(m2) m2 receive an event m2 receive an event m2 will call m1 m2 will call m1 28N.L. Hsueh, SE-Lab IECS FCU
  29. 29. Software Engineering Broadcasting Sy us bt - e s m Sy us bt - e s m Sy us bt - e s m Sy us bt - e s m 1 2 3 4 E am enr v n eg d e ds hl n t s ae a 29N.L. Hsueh, SE-Lab IECS FCU
  30. 30. Software Engineering Interrupt-driven systems  Used in real-time systems where fast response to an event is essential  There are known interrupt types with a handler defined for each type  Each type is associated with a memory location and a hardware switch causes transfer to its handler  Allows fast response but complex to program and difficult to validate 30N.L. Hsueh, SE-Lab IECS FCU
  31. 31. Software Engineering Interrupt-driven control Interrupts Interrupt vector Handler Handler Handler Handler 1 2 3 4 Process Process Process Process 1 2 3 4 31N.L. Hsueh, SE-Lab IECS FCU
  32. 32. Software Engineering Modular Decomposition 32N.L. Hsueh, SE-Lab IECS FCU
  33. 33. Software Engineering The problem that they have to deal with are complex, …, software engineers cannot reduce this complexity. However, it can be funneled and confined within weakly coupled closed areas. By judicious segmentation of the state space, the system is made easier 33N.L. Hsueh, SE-Lab IECS FCU
  34. 34. Software Engineering Modular decomposition  Sub-systems are decomposed into modules  Two modular decomposition models covered  An object model where the system is decomposed into interacting objects  A data-flow model where the system is decomposed into functional modules which transform inputs to outputs. Also known as the pipeline model  If possible, decisions about concurrency should be delayed until modules are implemented 34N.L. Hsueh, SE-Lab IECS FCU
  35. 35. Software Engineering Object models  Structure the system into a set of loosely coupled objects with well-defined interfaces  Object-oriented decomposition is concerned with identifying object classes, their attributes and operations  When implemented, objects are created from these classes and some control model used to coordinate object operations  Adv:  loosely coupled: the implementation of objects can be modified without affecting other objects  Easily modeled: objects are often representations of real-world entities 35N.L. Hsueh, SE-Lab IECS FCU
  36. 36. Software Engineering Invoice processing system Customer Receipt customer # invoice # name date address Invoice amount credit period customer # invoice # date amount customer Payment Issue invoice # Send reminder date Accept payment amount Send receipt customer # 36N.L. Hsueh, SE-Lab IECS FCU
  37. 37. Software Engineering Data-flow models  Functional transformations process their inputs to produce outputs  May be referred to as a pipe and filter model (as in UNIX shell)  Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems  Not really suitable for interactive systems  Adv.  It supports the reuse of transformations  It is intuitive in that many people think of their work in terms of input and output processing  Evolving the system by adding new transformations is usually straightforward  It is simple to implement either as a concurrent or a sequential system 37N.L. Hsueh, SE-Lab IECS FCU
  38. 38. Software Engineering Invoice processing system Issue Receipts receiptsR issued ead Identify invoices paym ents Find Issue pa e ym nts pa e ym nt R inders em due rem inder Invoices Paym nts e 38N.L. Hsueh, SE-Lab IECS FCU
  39. 39. Software Engineering Domain-Specific Architecture 39N.L. Hsueh, SE-Lab IECS FCU
  40. 40. Software Engineering Domain-specific architectures  Architectural models which are specific to some application domain  Two types of domain-specific model  Generic models which are abstractions from a number of real systems and which encapsulate the principal characteristics of these systems  May be reused directly in a design  Bottom-up models  Reference models which are more abstract, idealized model. Provide a means of information about that class of system and of comparing different architectures  Used to communicate domain concepts and compare possible architecture  Top-down models 40N.L. Hsueh, SE-Lab IECS FCU
  41. 41. Software Engineering Generic models  Compiler model is a well-known example although other models exist in more specialized application domains  Lexical analyzer  Symbol table  Syntax analyzer  Syntax tree  Semantic analyzer  Code generator  Generic compiler model may be organized according to different architectural models 41N.L. Hsueh, SE-Lab IECS FCU
  42. 42. Software Engineering A data-flow model of a compiler Sym bol table Lexical Syntactic Semantic Code analysis analysis analysis generation 42N.L. Hsueh, SE-Lab IECS FCU
  43. 43. Software Engineering The repository model of a language processing system Lexical Syntax Semantic analyser analyser analyser Pretty- Abstract Grammar printer syntax tree definition Optimizer Symbol Output Code Editor table definition generator Repository 43N.L. Hsueh, SE-Lab IECS FCU
  44. 44. Software Engineering Reference architectures  Reference models are derived from a study of the application domain rather than from existing systems  May be used as a basis for system implementation or to compare different systems. It acts as a standard against which systems can be evaluated  OSI model is a layered model for communication systems 44N.L. Hsueh, SE-Lab IECS FCU
  45. 45. Software Engineering OSI reference model 7 A p c ti n p li a o A p c ti n p li a o 6 Pe e t t n r s naio Pe e t t n r s naio 5 S ss n e io S ss n e io 4 Ta sp r r n ot Ta sp r r n ot 3 Ntw rk e o Ntw rk e o Ntw rk e o 2 Dtal k a in Dtal k a in Dt ln aa i k 1 P y ic l hs a P y ic l hs a P y ic l hs a C m u ic o s md m o mn ati n e iu 45N.L. Hsueh, SE-Lab IECS FCU
  46. 46. Software Engineering Design Pattern 46N.L. Hsueh, SE-Lab IECS FCU
  47. 47. Software Engineering 我們不只要做絲襪 , 我們要做 ‘超彈性’絲襪 47N.L. Hsueh, SE-Lab IECS FCU
  48. 48. Software Engineering What is a Pattern?  Current use comes from the work of the architect Christopher Alexander  Alexander studied ways to improve the process of designing buildings and urban areas  “Each pattern is a three-part rule, which expresses a relation between a certain context, a problem and a solution.”  Hence, the common definition of a pattern: “A solution to a problem in a context.”  Patterns can be applied to many different areas of human endeavor, including software development 48N.L. Hsueh, SE-Lab IECS FCU
  49. 49. Software Engineering Why Pattern?  "Designing object-oriented software is hard and designing reusable object-oriented software is even harder." - Erich Gamma  Experienced designers reuse solutions that have worked in the past  Well-structured object-oriented systems have recurring patterns of classes and objects  Knowledge of the patterns that have worked in the past allows a designer to be more productive and the resulting designs to be more flexible and reusable 49N.L. Hsueh, SE-Lab IECS FCU
  50. 50. Software Engineering History  1987 - Cunningham and Beck used Alexander’s ideas to develop a small pattern language for Smalltalk  1990 - The Gang of Four (Gamma, Helm, Johnson and Vlissides) begin work compiling a catalog of design patterns  1991 - Bruce Anderson gives first Patterns Workshop at OOPSLA  1993 - Kent Beck and Grady Booch sponsor the first meeting of what is now known as the Hillside Group  1994 - First Pattern Languages of Programs (PLoP) conference  1995 - The Gang of Four (GoF) publish the Design Patterns book 50N.L. Hsueh, SE-Lab IECS FCU
  51. 51. Software Engineering Types of software patterns  Analysis  Design  Organizational  Process  Project Planning  Configuration Management 51N.L. Hsueh, SE-Lab IECS FCU
  52. 52. Software Engineering Types of software patterns  Riehle and Zullighoven in “Understanding and Using Patterns in Software Development” mention three types of software patterns  Conceptual Pattern  Pattern whose form is described by means of terms and concepts from the application domain  Design Pattern  Pattern whose form is described by means of software design constructs, such as objects, classes, inheritance and aggregation  Programming Pattern (Programming Idiom)  Pattern whose form is described by means of programming language constructs 52N.L. Hsueh, SE-Lab IECS FCU
  53. 53. Software Engineering Design Pattern Level of Abstraction  Complex design for an entire application or subsystem More abstract  Solution to a general design problem in a particular context More concrete  Simple reusable design class such as a linked list, hash table, etc. 53N.L. Hsueh, SE-Lab IECS FCU
  54. 54. Software Engineering GoF Design Patterns  The GoF design patterns are in the middle of these levels of abstraction  “A design pattern names, abstracts, and identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design.”  The GoF design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” 54N.L. Hsueh, SE-Lab IECS FCU
  55. 55. Software Engineering GoF Classification Of Design Patterns  Purpose - what a pattern does  Creational Patterns  Concern the process of object creation  Structural Patterns  Deal with the composition of classes and objects  Behavioral Patterns  Deal with the interaction of classes and objects  Scope - what the pattern applies to  Class Patterns  Focus on the relationships between classes and their subclasses  Involve inheritance reuse  Object Patterns  Focus on the relationships between objects  Involve composition reuse 55N.L. Hsueh, SE-Lab IECS FCU
  56. 56. Software Engineering GoF Essential Elements Of Design Patterns  Pattern Name  Having a concise, meaningful name for a pattern improves communication among developers  Problem  What is the problem and context where we would use this pattern?  What are the conditions that must be met before this pattern should be used?  Solution  A description of the elements that make up the design pattern  Emphasizes their relationships, responsibilities and collaborations  Not a concrete design or implementation; rather an abstract description  Consequences  The pros and cons of using the pattern  Includes impacts on reusability, portability, extensibility 56N.L. Hsueh, SE-Lab IECS FCU
  57. 57. Software Engineering GoF Pattern Template  Structure A graphical representation of the pattern  Participants  The classes and objects participating in the pattern  Collaborations  How to do the participants interact to carry out their responsibilities?  Consequences  What are the pros and cons of using the pattern?  Implementation  Hints and techniques for implementing the pattern 57N.L. Hsueh, SE-Lab IECS FCU
  58. 58. Software Engineering GoF Pattern Template  Pattern Name and Classification A good , concise name for the pattern and the patterns type  Intent  Short statement about what the pattern does  Also Known As  Other names for the pattern  Motivation  A scenario that illustrates where the pattern would be useful  Applicability  Situations where the pattern can be used 58N.L. Hsueh, SE-Lab IECS FCU
  59. 59. Software Engineering GoF Pattern Template  Sample Code Code fragments for a sample implementation   Known Uses  Examples of the pattern in real systems  Related Patterns  Other patterns that are closely related to the pattern 59N.L. Hsueh, SE-Lab IECS FCU
  60. 60. Software Engineering Key points  The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model  System decomposition models include repository models, client-server models and abstract machine models  Control models include centralised control and event-driven models 60N.L. Hsueh, SE-Lab IECS FCU
  61. 61. Software Engineering Key points  Modular decomposition models include data-flow and object models  Domain specific architectural models are abstractions over an application domain. They may be constructed by abstracting from existing systems or may be idealised reference models 61N.L. Hsueh, SE-Lab IECS FCU
  62. 62. Software Engineering The architectural model provides a Gestalt view of a system, allowing the software engineering to examine it as a whole R. Pressman 62N.L. Hsueh, SE-Lab IECS FCU