Docstoc

ARCHITECTURE

Document Sample
ARCHITECTURE Powered By Docstoc
					                                           Software Engineering




                      Software Architecture

                              N.L. Hsueh




                                                           1
N.L. Hsueh, SE-Lab IECS FCU
                                          Software Engineering

                               Outline

       Basic Concept
       Architecture Styles

         Control models
         Modular decomposition
         Domain-specific architectures
         Design Pattern




                                                          2
N.L. Hsueh, SE-Lab IECS FCU
                                                    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




                                                                      3
N.L. Hsueh, SE-Lab IECS FCU
                                                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




                                                                    4
N.L. Hsueh, SE-Lab IECS FCU
                                                  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




                                                                       5
N.L. Hsueh, SE-Lab IECS FCU
                                                    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




                                                                         6
N.L. Hsueh, SE-Lab IECS FCU
                                                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




                                                                    7
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering




                         Architectural Style




                                                               8
N.L. Hsueh, SE-Lab IECS FCU
                                     Software Engineering

            1. Main Program With Subroutines




                                                     9
N.L. Hsueh, SE-Lab IECS FCU
                                                         Software Engineering


                                      Control


         Input                Shift               Sort         Output



                   store                 shifts           sorted

         input
                                                                output
                  Procedure call
                  Access to data structure
                  i/o
                                                                         10
N.L. Hsueh, SE-Lab IECS FCU
                                          Software Engineering

                      2. Abstract Data Type


                              Control


         Input                                   Output



              Store            Shift          Sort


        output                                   output


                                                          11
N.L. Hsueh, SE-Lab IECS FCU
                                                      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()


                                                                            12
N.L. Hsueh, SE-Lab IECS FCU
                              Software Engineering



       Shift
          ShiftLines()
          ShiftWords(l)
          ShiftChars(l,w)
          ShiftChar(l,w,c)
       Sort
          iniSort
          getIndex(w)




                                              13
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering

                      3. Implicit Invocation

                                    Control




         Input           MakeShift              Sort          Output



     input          Store               Shift                 output


                              Implicit call     The MakeShift module is
                                                no explicitly called
                                                                          14
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering

                          4. Pipe and Filter




         Input                Shift     Sort         Output



         input                                        output




                                                               15
N.L. Hsueh, SE-Lab IECS FCU
                                                  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




                                                                      16
N.L. Hsueh, SE-Lab IECS FCU
                                       Software Engineering

                              Conti.




                                                       17
N.L. Hsueh, SE-Lab IECS FCU
                                               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




                                                                  18
N.L. Hsueh, SE-Lab IECS FCU
                                           Software Engineering

                              6. Layered




                                                           19
N.L. Hsueh, SE-Lab IECS FCU
                                                 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




                                                                     20
N.L. Hsueh, SE-Lab IECS FCU
                                                         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




                                                                           21
N.L. Hsueh, SE-Lab IECS FCU
                                              Software Engineering




                              Control Model




                                                              22
N.L. Hsueh, SE-Lab IECS FCU
                                                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



                                                                    23
N.L. Hsueh, SE-Lab IECS FCU
                                                   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.




                                                                        24
N.L. Hsueh, SE-Lab IECS FCU
                                                              Software Engineering

                            Call-return model

                                         Main
                                        program




              Routine 1                 Routine 2             Routine 3




    Routine 1.1           Routine 1.2               Routine 3.1           Routine 3.2




                                                                                        25
N.L. Hsueh, SE-Lab IECS FCU
                  A centralized control model Engineering
                                           Software
                     for a real-time system
                             control


                 Sensor                     Actuator
                processes                   processes




                               System
                              contr oller




          Computation           User             Fault
           processes          interface         handler

                                                          26
N.L. Hsueh, SE-Lab IECS FCU
                                                 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



                                                                     27
N.L. Hsueh, SE-Lab IECS FCU
                                                     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
                               m1.registerTo(m2)
                               m2 receive an event
                               m2 will call m1
                                                                      28
N.L. Hsueh, SE-Lab IECS FCU
                                                             Software Engineering

                                Broadcasting



  Sub-system           Sub-system               Sub-system         Sub-system
      1                     2                       3                   4




                              Event and messa ge handler




                                                                                29
N.L. Hsueh, SE-Lab IECS FCU
                                                  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




                                                                       30
N.L. Hsueh, SE-Lab IECS FCU
                                                               Software Engineering

                     Interrupt-driven control

                                        Interrupts



               Interrupt
                 vector




           Handler            Handler                Handler      Handler
              1                  2                     3             4



           Process            Process                Process       Process
              1                  2                      3             4


                                                                               31
N.L. Hsueh, SE-Lab IECS FCU
                                        Software Engineering




                     Modular Decomposition




                                                        32
N.L. Hsueh, SE-Lab IECS FCU
                                         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




                                                         33
N.L. Hsueh, SE-Lab IECS FCU
                                                 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




                                                                     34
N.L. Hsueh, SE-Lab IECS FCU
                                                  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




                                                                      35
N.L. Hsueh, SE-Lab IECS FCU
                                               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 #



                                                               36
N.L. Hsueh, SE-Lab IECS FCU
                                                             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



                                                                                      37
N.L. Hsueh, SE-Lab IECS FCU
                                              Software Engineering
                         Invoice processing
                               system



                                  Issue
                                            Receipts
                                 receipts

Read issued        Identify
  invoices        payments
                                  Find        Issue
                                payments    payment      Reminders
                                   due      reminder
  Invoices        Payments




                                                                38
N.L. Hsueh, SE-Lab IECS FCU
                                       Software Engineering




                Domain-Specific Architecture




                                                       39
N.L. Hsueh, SE-Lab IECS FCU
                                                        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

                                                                         40
N.L. Hsueh, SE-Lab IECS FCU
                                               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




                                                                41
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering

              A data-flow model of a compiler


                                   Symbol
                                    table




   Lexical             Syntactic            Semantic            Code
   analysis            analysis             analysis          generation




                                                                           42
N.L. Hsueh, SE-Lab IECS FCU
                                                                 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

                                                                                     43
N.L. Hsueh, SE-Lab IECS FCU
                                                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




                                                                   44
N.L. Hsueh, SE-Lab IECS FCU
                                                       Software Engineering

                        OSI reference model


      7     Application                                Application

      6     Presentation                               Presentation

      5     Session                                    Session

      4     Transport                                  Transport

      3     Network               Network              Network

      2     Data link             Data link            Data link

      1     Physical              Physical             Physical

                              Communica tions medium

                                                                       45
N.L. Hsueh, SE-Lab IECS FCU
                                               Software Engineering




                              Design Pattern




                                                               46
N.L. Hsueh, SE-Lab IECS FCU
                              Software Engineering




         我們不只要做絲襪, 我們要做 ‘超彈性’絲襪




                                              47
N.L. Hsueh, SE-Lab IECS FCU
                                                          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



                                                                          48
N.L. Hsueh, SE-Lab IECS FCU
                                                        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




                                                                              49
N.L. Hsueh, SE-Lab IECS FCU
                                                      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




                                                                         50
N.L. Hsueh, SE-Lab IECS FCU
                                         Software Engineering

                  Types of software patterns

       Analysis
       Design
       Organizational
       Process
       Project Planning
       Configuration Management




                                                         51
N.L. Hsueh, SE-Lab IECS FCU
                                                         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




                                                                                52
N.L. Hsueh, SE-Lab IECS FCU
                                           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.




                                                           53
N.L. Hsueh, SE-Lab IECS FCU
                                                         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.”




                                                                               54
N.L. Hsueh, SE-Lab IECS FCU
                                                                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

                                                                                    55
N.L. Hsueh, SE-Lab IECS FCU
                                                              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



                                                                                      56
N.L. Hsueh, SE-Lab IECS FCU
                                                          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




                                                                          57
N.L. Hsueh, SE-Lab IECS FCU
                                                          Software Engineering

                       GoF Pattern Template

       Pattern Name and Classification
           A good , concise name for the pattern and the pattern's 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




                                                                            58
N.L. Hsueh, SE-Lab IECS FCU
                                                           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




                                                                           59
N.L. Hsueh, SE-Lab IECS FCU
                                                     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




                                                                          60
N.L. Hsueh, SE-Lab IECS FCU
                                                 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




                                                                     61
N.L. Hsueh, SE-Lab IECS FCU
                                          Software Engineering




         The architectural model provides a Gestalt view
         of a system, allowing the software engineering
         to examine it as a whole

         R. Pressman




                                                           62
N.L. Hsueh, SE-Lab IECS FCU

				
About if any file u wil find copyright contact me it will be remove in 3 to 4 buisnees days. add me on sanjaydudeja007@gmail.com or visit http://www.ohotech.com/