Docstoc

1 - Web Services Overview

Document Sample
1 - Web Services Overview Powered By Docstoc
					Spam Filter Exercise II: Part 2
Revision 1.0                                                                                             OMSE 532
Last Print Date: 9/22/2011 - 6:55 PM                                                                     Grant McCord




Table of Contents
1. Quality Attribute Scenarios ................................................................................................. 2
  1.1    Filter Upgrade Scenario .......................................................................... 2
  1.2    Interoperability Scenario ........................................................................ 2
    1.2.1     Assumptions ......................................................................................................... 3
  1.3    Market Growth Scenario ......................................................................... 3
    1.3.1     Assumptions ......................................................................................................... 3
2. Architecture Views ............................................................................................................. 3
  1.4    Layered Module View ............................................................................. 4
  1.5    Process View ......................................................................................... 4
3. Layered Module Design Views............................................................................................. 5
  1.6    Primary Presentation.............................................................................. 5
  1.7    Element Catalog .................................................................................... 6
  1.8    Context Diagram ................................................................................... 6
  1.9    Architecture Background ........................................................................ 7
4. Process View ..................................................................................................................... 8
  1.10      Primary Presentation........................................................................... 8
  1.11      Element Catalog ................................................................................. 9
  1.12      Architecture Background ..................................................................... 9
1. Quality Attribute Scenarios
    These driver scenarios are based on the Spam Filter requirements and will be used in developing
the design of the product.


1.1 Filter Upgrade Scenario
   This scenario represents the customer requirement to apply upgrades to the spam filter criteria on
any customer platform. This capability has been isolated as a key business goal and has critical
importance to the software architecture.

Source             Filter maintenance personnel; those responsible for determining when a filter
                   upgrade is needed and supplying that upgrade to product consumers.
Stimulus           Run time to update of spam filter criteria on the consumer system.
Artifact           The algorithm used on the client system to identify email spam.
Environment        A run time patch is necessary; software must maintain execution during, and after
                   integration of new spam filter criteria.
Response           A new threat is identified by those responsible for maintaining spam filter criteria.
                   Software changes are identified to address the new need (address new threat).
                   Software is packaged for deployment to customers and released.
Response           Spam filter criteria can be altered with minimal development effort. Some criteria
Measure            may be applied by non-development personnel in the organization (i.e. customer
                   support). Customer release packages can be tested quickly to minimize delay in
                   deployment.


1.2 Interoperability Scenario
   An important business goal was integration of the software into existing email programs such as
Eudora, Netscape, or Outlook.

Source                  ABC customers who use 3rd party email programs (i Eudora, Netscape,
                        Outlook)
Stimulus                ABC decides which client email programs must have product compatibility.
Artifact                The algorithm used on the client system to identify email spam.
Environment             Configuration of 3rd party email programs to interoperate with the filter
                        software.
Response                A means of installation is provided for the spam filter software to work with
                        existing client email programs. This can include but is not limited to
                        instructions or utilities that facilitate setup.
Response Measure        After a setup is complete, operation of the 3rd party email clients with the spam
                        filter is seamless.


OMSE 531                                                                                          Page 2
1.2.1 Assumptions

    Configuration. If configuration changes are required in client email programs, these must be
limited to 1-2 setting changes. Any changes required to these customer email programs must be
completed by the consumer.

     No Interference. The solution cannot interfere with the operation (install, use, uninstall) of these
client email programs in any way, either directly or indirectly. Modifications to registry entries or files
these programs use is not acceptable.

    No Interface Constraints. There are no interface constraints known at this time. For example,
the solution does not need to consume or provide .dlls to 3rd party email programs.

   Minimum Compatibility. The ABC company will provide the minimum 3rd party email clients to be
supported. Exceeding this minimum list is encouraged


1.3 Market Growth Scenario
    Business analysis identified a small but growing portion of ABC customers read email on personal
data accessories (phones, hand held organizers). Future product growth onto these platforms must be
planned in the existing product architecture. Thus, the must support expansion to these data
accessories that support execution of commercial software

Source                   ABC Marketing (and Product Development Team)
Stimulus                 Roadmap; ABC wants to expand the spam filter software to the PDA market
                         with a roadmap for device support.
Artifact                 The initial set of PDA devices the Spam Filter program must be modified to
                         operate on.
Environment              The impact to development to adapt the Spam Filter program to support
                         existing product features on PDAs.
Response                 Spam Filter program is developed, after requirements and schedule is fulfilled,
                         that operates on client PDAs.
Response Measure         Spam Filter for PDAs meets product roadmap


1.3.1 Assumptions

       Unknown Roadmap. The product roadmap for personal accessories is not known at this time.
Any personal data accessory which can be used to read email may be targeted for product support.

       Client Solution. Spam filter software will be installed on the client device. Filtering at ISP
servers for clients using browser based email clients from PDAs does not satisfy the business goal.



2. Architecture Views
  The types of views and reasons for each will be described below:
OMSE 531                                                                                           Page 3
1.4 Layered Module View
    The module view shows the dependencies between modules in the software. The goal is to divide
the software into logical segments and then show their dependency upon each other through layering.
Use of the module view addresses these concerns:

   Design Decisions
      1) The software can be broken up into functional categories (modules) that communicate
         through well defined interfaces.
      2) Modules have limited communication with each other and their communication partners are
         organized in the view by layering them and drawing information exchange paths.
      3) Dividing a software project into distinct modules allows different development teams to
         work on each, thus achieving some parallel development.
      4) Exchange of email between machines involves passing through many layers (network,
         application, hardware). Modeling the software architecture after network communication
         architecture allows us to capitalize on some of the design efficiencies already present. It
         also makes the architecture that much easier to understand as an extension of an existing
         architecture (data exchange between client and servers).
      5) A user interface is not necessary for the program to run; it is launched only when the user
         needs to view statistics or change settings. Otherwise, it can be closed and the application
         can still run.

   Design Drivers Satisfied
      1) Future PDA market growth into means that parts of the software is likely to change to
         accommodate the new customer platforms. However, not all the software has to change.
         Thus, through modularization, we can isolate those parts which are most like to be affected
         by a platform change and leave the other modules intact. This minimizes the work needed
         to support new platforms in the future and satisfies emergent business needs at the same
         time.
      2) Supporting frequent filter upgrades demands that the filter mechanism in the software be
         separated as much as possible – because it will be changing so much. We need to isolate
         that part of the system to support the business goals of frequent updates. The layered
         module view can demonstrate which parts of the system are affected by the filter upgrade
         capability and which parts are unaffected.

   Primary Audiences
       1) Product Manager – the product manager will use the view to understand the parts of the
          system which need to be completed. It is a communication vehicle about progress between
          the development team and management.
       2) Development Team – the development team uses this view to distribute the work internally.
          Modules can be assigned to different sub-teams for completion.
       3) Test Organization – the test organization uses this view to identify the applications’
          boundaries and interfaces (how they will get the testing done).
       4) Architect – the architect needs this view to discuss the software with all stakeholders. It
          provides a vocabulary of terms to distribute information.

1.5 Process View


OMSE 531                                                                                      Page 4
    The process view will be created to as a means of communication between development team
members. Showing data flow through the system modules will help identify interfaces, communication
dependencies, run time behavior, and the responsibility of each module to information exchange
activities.

   Design Decisions
      1) Concentrate the main processing for the system into a single entity (the application
         manager for the application layer). This process contains most of the “brains” of the system
         and coordinates all the programs activities in a single place.
      2) Modules which contain pieces likely to change are isolated away from the main program and
         have distinct interfaces. This helps shield the architecture from platform constraints when
         the product moves to new markets.

   Design Drivers Satisfied
      1) Interoperability with 3rd party email programs requires information exchange. We need to
         present where we expect the data to come in to the system and how it will be returned
         from these commercial email programs. This view will demonstrate the data paths and
         interfaces that will be implemented for these commercial email clients.

   Primary Audiences
      1) Development Team – the development team will be the primary consumers of this view; it
         shows them the internal data flow for the program.
      2) Architects – existing and future architects will use this view to discuss tradeoffs with the
         design team.


3. Layered Module Design Views
    The module view has been designed to be simple and straightforward. It shows the modules of the
system and their relationship to each other. Also, it accounts the three main business concerns; it
shows the primary drivers have a representation in the architecture somewhere.

1.6 Primary Presentation

        User Interface



       Application Layer            Scan Engine           Filter


         Service Layer
                                             Data exchange paths

       Transport Layer
           Laptop/Server/     PDA Phone
              Desktop


OMSE 531                                                                                       Page 5
1.7 Element Catalog
     User Interface – The user interface for the program has been separated. For most systems,
     this will be an on-demand interface for configuring the application service. The application
     service will continue to run regardless if the user interface is loaded or not.
          Means through which users view settings or change them
          Users can view statistical data here

     Application Layer – This is the main program that coordinates email filtering, interfaces with
     user configuration requests, schedules activities, and email queues. It is also responsible for
     turning off the scan engine to update a filter and invoking the scan engine when it is needed.
          Applies spam filter upgrades by turning off the scan engine to update the filter file.
          Invokes scan engine on a “as needed” basis (depending on user settings)
          Manages message queues to the service layer
          Saves customer configurations and settings

     Scan Engine – The scan engine is a driver library that is loaded into memory when needed by
     the application layer to scan user email.
          A threaded driver library that scans email messages passed to it based on filter criteria
          Is unloaded when not in use
          Consumes the filter information, cannot modify it.

     Filter – This contains the spam definitions which are to be updated regularly.
          Global repository for spam characterization
          Can be updated only by the application layer

     Service Layer – This layer handles data formatting requirements between the application layer
     and the transport layer. It is a pass through mechanism and translator that shields the
     application layer from different communication protocols.
         Facilitates communication and data translation between the application layer and the
             transport layer.
         Functions as an operating system service on laptops, desktops.

     Transport Layer – This layer is a communication driver that interfaces the software with the
     platform operating system. These two layers will be requiring significant rework for different
     clients such as PDAs and cellular phones.
          A virtual device driver in the system, this is the gateway for all email requests and sends
             from the software.


1.8 Context Diagram




OMSE 531                                                                                      Page 6
        Application



     EMAIL on TCP/IP



     3rd PARTY EMAIL




1.9 Architecture Background
  Goals with this view:
    1) Abstract out implementation details to show a high level overview of the software.
    2) Show basic relationship between components
    3) Demonstrate isolation of the Filter – which will be upgraded regularly.
         Also show relationship between the filter and the scan engine.
    4) Isolate platform dependencies from the application (service, transport layers
    5) Show a dependency model similar to network communications between clients which have
        an application sitting on top of network protocols
    6) Introduce how the architecture accounts for emergent market needs (PDA, Phone)
    7) Show which modules will need to be written for PDAs and hand-held support.

  Design Rationale
     1) The scan engine has been separated from the application layer to allow the scan engine to
        unload when it is not in use. This was done to help performance on PDAs, where memory
        and processor resources may be constrained. Thus, the application supports a “scan on
        demand” function rather than operating all the time.
     2) The scan engine is a threaded driver library that will operate in the same process, but in
        another thread as the application layer.
            a. Assumption: PDAs and cell phones support multi-threaded applications.
     3) The filter has been isolated outside the application layer and has a consumer relationship
        with the scan engine. The application layer must be used to update the filter, it cannot be
        patched through any other means.
     4) Use of the software on many different platforms meant three pieces needed to be isolated:
        the user interface, transport layer and the service layer.
     5) 3rd party email programs will interface with the program at the transport layer, and are thus
        represented in the context diagram.

  Design Tradeoffs
     1) This design demonstates what will be needed to support future market growth into the PDA
        and handheld market. Due to this archtiectural driver, the software architecture is more
        layered than would be needed for support of only client and server computer systems.




OMSE 531                                                                                      Page 7
  Assumptions
     1) Filter criteria updates may be provided to consumers in a variety of methods (FTP
        downloads, web sites, email) and formats (laptops, desktops, servers, hand-helds, phones).
        The solution should be independent of consumer connection, platform, and file format.
     2) All software will require initiation by the consumer to apply the filter upgrades. Whether this
        is scheduled, or manually initiated, it will be known to the software’s algorithms that a
        consumer is requesting a filter upgrade.



4. Process View
1.10 Primary Presentation

           User Interface



            APPLICATION                             SCAN
             MANAGER                                QUEUE
                                                                         Scan Engine

                                                     User                           Filter
                                                    Settings
       SEND       RECEIVE
       QUEUE       QUEUE                   Application Layer




        TRAFFIC MONITOR

       DATA TRANSLATOR                                         VIRTUAL NIC

           LOAD MODULE                                      Transport Layer


           Service Layer
                                                           TCP/IP STACK
                     Bi-directional process flow

                     Uni-directional process flow         3rd Party Email Clients




OMSE 531                                                                                        Page 8
1.11 Element Catalog
           Application Layer
                     Application Manager – Manages queues and user interface interactions; it also
                      responsible for loading the service layer if it is not loaded for some reason.
                     Scan Queue – A queue of email to be scanned by the scan engine.
                     User Settings – User specific settings, these may also include additional filtering
                      criteria added by the user.
                     Send Queue – Queue for email to be sent
                     Receive Queue – Queue for email to be scanned

           Service Layer
                     Traffic Monitor – Checks the send queue of the application, or places new emails
                      into the application receive queue.
                     Data Translator– Translates data format between specific platforms into a format
                      the application layer can understand.
                     Load Module – Loads the service layer and checks user settings file for
                      configuration information.

           Transport Layer
                     Virtual NIC – A virtual networking device in the computer system; this device has
                      an IP address that client email programs send/receive email from.

           3rd Party Email Clients
                                                                             rd
                   This is the part of the architecture that addresses how 3 party email clients will
                      interface with the program.

1.12 Architecture Background
  Goals with this view:
    1) Show processing between modules and components inside each module.
    2) Demonstrate how 3rd party program email programs can use this software to filter email.

  Design Rationale
     1) The application manager saves user settings to a local data store, which can be read by the
        service layer for configuration data.
     2) All email data to and from the application layer occurs in two queues (send, receive). Since
        the application is a virtual mail server on the client machine, this allows for processing send
        and receives traffic.
     3) The user interface layer only communicates with the application manager, even to change
        configuration settings.

  Design Tradeoffs
     1) The majority of the application logic sits in the application manager, in the application layer.
        The program will have a primary controller with ancillary libraries and functions to support
        its operation. This might be slower, but it asserts greater control over what is occuring in
        the program.



OMSE 531                                                                                           Page 9
    <<Overall well organized and clearly written. Does a good job of connecting the architectural
design decisions with stakeholder goals. Might be clarified by some additional discussion on goals up
front but that may be an artifact of disconnecting parts 1 and 2.

    Overall, shows good understanding of the process and used of the documentation components
(diagrams, element catalog, etc.).

>>




OMSE 531                                                                                        Page
10

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:9/23/2011
language:English
pages:10