Docstoc

04

Document Sample
04 Powered By Docstoc
					                  System Modelling

                            Week 9




CSE2200 - System Design and Implementation   Lecture 9
                     Lecture Outline

      Uni-SEP and the System Design Stage
      System Modelling
         Extending the Business Model
         Defining the System Scenarios
         Component Specification
         Building a System Architecture (week 8)




CSE2200 - System Design and Implementation          Lecture 9
               System Definition Phase
                                      System Definition
                      Problem Qualification                System Design
                      Stage                                Stage



                          RM           RM                           RM


         Project                                                                   Development
                                                         SM         SM     SM
      Investigation

                          UI           UI                           UI
                                                                                      Process Legend:

                                 PT                                 PT                RM - Requirements Modelling
                                                                                      SM - System Modelling
                                                                                      UI - User Interface Modelling
                                 PM                                 PM                PT - Prototyping
                                                                                      PM - Project Management
                                                                                      QA - Quality Assurance
                                                                    QA                TM - Test Management
                                 QA


                                TM                                  TM




                                            Problem Qualification          System Design
                                                  Release                     Release




CSE2200 - System Design and Implementation                                                              Lecture 9
             The System Design Stage

      System design builds on the core
       Requirements Model
      We will be performing the following Process
       Units
         User Interface Modelling
         System Modelling
         Prototyping
      Deliverables are
         System Model
         Prototype




CSE2200 - System Design and Implementation   Lecture 9
             System Design Activities

      System Modelling
         Precursor - Requirements Model
         Architectural Design
         Solution Domain Modelling
         Component Specification
      User Interface Modelling
         Precursor - Initial Design via View Navigation Diagrams
         Interface Design
         Interface Development
      Prototyping
         Building and reviewing the prototype



CSE2200 - System Design and Implementation                Lecture 9
              Uni-SEP and Software
                  Architecture
                System Modelling

                                           uses


                  Architectural
                    Analysis                                 Solution Domain
                                                     uses
                                                                Modelling
                                                             uses   uses
                                   Architectural
                                      Design

                                                              Development
                                    uses          uses      uses Planning

Architect
                           Component Specification



CSE2200 - System Design and Implementation                                  Lecture 9
        System Modelling in CSE2200

      Creating the Solution Domain Model
      Defining the System Scenarios
      Component Specification
      Building a System Architecture




CSE2200 - System Design and Implementation   Lecture 9
          The Solution Domain Model
      Is an extension of the Business Model to
       accommodate how we will provide a solution
       to the business requirements
      it will incorporate
         business classes
         interface classes (as identified in our user interface
          modelling)
         control classes
         infrastructure/framework components
      Takes us from analysis to design
      Not tied to a particular technology, but does
       identify the mechanisms to tie it to the final
       technology

CSE2200 - System Design and Implementation                   Lecture 9
                   Scenarios in Uni-SEP


          What the                              Model of the
        system does     Business Scenarios       Business




          How the                                  Model of
       system does it   System Scenarios     the Software System




CSE2200 - System Design and Implementation                     Lecture 9
                   System scenarios

      System Scenarios focus on how the system
       will provide a solution to the Business
       Scenarios
      Business Scenarios are specified in UML by
       Use Cases
      System Scenarios are specified in UML by
       Interaction Diagrams
      Two types of Interaction Diagram
         Sequence Diagrams
         Collaboration Diagrams




CSE2200 - System Design and Implementation   Lecture 9
               Interaction Diagrams

      Models which show how groups of objects
       collaborate in some behaviour
      Typically we describe how the behaviour of a
       single use case is implemented by a group of
       objects and the messages they pass between
       them
      We also use them to describe interactions
       between the components of the system which
       are not directly related to business scenarios
       if we need to



CSE2200 - System Design and Implementation    Lecture 9
           Expanded Use Case Example

Use Case:              Buy Items with Cash
Actors:                Customer (initiator), Cashier
Purpose:               Capture a sale and its cash payment
Overview:              A Customer arrives at a checkout with items
                       to purchase. The Cashier records the
                       purchase items and collects a cash
                       payment. On completion, the Customer
                       leaves with the items.
Type:                  primary and essential
Cross references:      R1.1, R1.2, R1.7




CSE2200 - System Design and Implementation             Lecture 9
              Expanded Use Case (2)
                  TYPICAL COURSE OF EVENTS
           ACTOR ACTION                      SYSTEM RESPONSE

   1. This use case begins
      when a Customer arrives
      at the register with items
      to purchase.
   2. The cashier records the      3. Determines the item price
      identifier from each item.   and adds the item information
      If more than one of the      to the running sales
      same item, the Cashier       transaction. The description
      can enter the quantity as    and price of the item are
      well.
                                   presented.
   4. Cashier indicates            5. Calculates and presents the
      completion of item entry.    sale total.
   6. Cashier tells the
      Customer the total.

CSE2200 - System Design and Implementation               Lecture 9
              Expanded Use Case (3)
          ACTOR ACTION                       SYSTEM RESPONSE

   7. The Customer gives a
      cash payment - possibly
      greater than the sale
      total.
   8. The Cashier records the         9. Show the balance due
      cash received amount.           back to the Customer.
                                      Generates a receipt.
   10. The Cashier deposits           11. Logs the completed
     the cash received and            sale.
     extracts the balance
     owing. Cashier gives
     balance and receipt to
     Customer.
   12. Customer leaves with
     items purchased.
CSE2200 - System Design and Implementation              Lecture 9
                   The Class Model




CSE2200 - System Design and Implementation   Lecture 9
          The Collaboration Diagram


                                             Display Panel




CSE2200 - System Design and Implementation      Lecture 9
             The Sequence Diagram




CSE2200 - System Design and Implementation   Lecture 9
             Collaboration Diagram
                  Components

               An object - object name: object class

                 1: * [condition] message name


                A message passing between objects
                1 - number indicates time order
                1.1 - shows nesting
                * - indicates repetition
                            link between 2 objects
CSE2200 - System Design and Implementation             Lecture 9
      Sequence Diagram Components
               Object



        Object lifeline


          Message name * for repetition
                       [ ] for condition

          Focus of control
          {timing constraint}


CSE2200 - System Design and Implementation   Lecture 9
                  Sequence Diagrams

      Sequence diagrams give good emphasis to
       the sequence of events
         flow of control by time ordering
      A sequence diagram can only show one flow
       of control (apart from simple iteration and
       branching)
      Will possibly need to have several diagrams
       for each use case




CSE2200 - System Design and Implementation   Lecture 9
        Creating a Sequence Diagram
      Identify relevant objects for the scenario
      Place the most important objects on the left
       and their neighbouring objects on the right
      Set the lifeline for each object
      Starting with the message which initiates the
       interaction, lay out each subsequent message
       form top to bottom
      If you need to specify
         computation, use focus of control
         time or space constraints, use {constraint}
         more formally, add pre and post conditions to each
          message


CSE2200 - System Design and Implementation                Lecture 9
              Collaboration Diagrams

      Collaboration diagrams show well the
       relationships between the classes
         flow of control by organisation
      Like a sequence diagram, a collaboration
       diagram can only show one flow of control
       (apart from simple iteration and branching)
      You will also need to have several
       collaboration diagrams to describe a use case
       fully




CSE2200 - System Design and Implementation    Lecture 9
    Creating a Collaboration Diagram
       Decide on the context for the collaboration
        diagram
       Identify the relevant objects and then place
        them in the diagram, the important ones in
        the centre and the neighbouring objects
        around the outside
       Specify the links between the objects
          Firstly the association links
          Then other links such as parameters
       Start with the message which initiates the
        interaction, attach it to the appropriate link
        and so on

CSE2200 - System Design and Implementation        Lecture 9
    Creating a Collaboration Diagram

      If you need to specify
         nesting, use Dewey decimal numbering
         time or space constraints, use {constraint}
         more formally, add pre and post conditions to each
          message




CSE2200 - System Design and Implementation                Lecture 9
                       Hints and Tips

      A well-structured interaction diagram:
         is focused on communicating one aspect of a system’s
          dynamics
         contains only those elements that are essential to
          understanding that aspect
         provides detail consistent with its level of abstraction and
          should expose only those adornments that are essential
          to understanding
         Is not so minimalist that it misinforms the reader about
          semantics that are important




CSE2200 - System Design and Implementation                  Lecture 9
                     Hints and Tips

      When you draw an interaction diagram
         give it a name that communicates its purpose
         use a sequence diagram to emphasise time ordering
         use a collaboration diagram to emphasise the
          organisation of the involved objects
         minimise crossing lines
         use branching sparingly




CSE2200 - System Design and Implementation             Lecture 9
             Component Specification

      We now flesh out the details of the
       components we have chosen
      In the assignment, each of our components
       will be a class
      Need to identify
         the role of the component
         Attributes
         Operations
         Type of component (business, control or interface)
      We can’t program responsibilities directly


CSE2200 - System Design and Implementation                Lecture 9
                     Component Types
                      Models information in the system that should
      <<business>>    be held for a longer time and typically survives
                      a use case

                       Models behaviour and information in the system
     <<boundary>>
                       that is dependent on the interface to the system,
                       often user interface related

                      Models functionality that is not naturally tied to any
      <<control>>     object, for example behaviour that consists of
                      operating on several different entity objects, doing
                      some computations and then returning the result to
                      an interface object


CSE2200 - System Design and Implementation                     Lecture 9
                Why control objects?

      OO systems are designed to be resistant to
       change
      Resistance depends upon the type of change
      Example
         Banking system with accounts
         Class Account - Open, Deposit, Withdraw
         Sub-classes - Passbook, Cheque, Christmas
      Changes
         add a moneymarket account
         add a report function to account




CSE2200 - System Design and Implementation            Lecture 9
                 The business model




CSE2200 - System Design and Implementation   Lecture 9
             Solution Domain Model




CSE2200 - System Design and Implementation   Lecture 9
               Why control objects?

      By moving the functionality to the control
       object Report, we have moved the report-
       specific issues to the abstraction Report
      Thus now any changes to report are localised
       to the one object and its clients (if the
       interface changes)
      Should not just use objects which correspond
       to real-life entities




CSE2200 - System Design and Implementation   Lecture 9
            A Software Architecture
      Is the organisation of a software system
      The selection of the structural elements and
       their interfaces by which the system is
       composed
      Their behaviour, as specified in the
       collaborations among those elements
      the composition of these structural and
       behavioral elements into progressively larger
       sub-systems
      The architectural style that guides this
       organisation: the static and dynamic
       elements and their interfaces, economic and
       technology constraints, their collaborations,
       and their composition.

CSE2200 - System Design and Implementation    Lecture 9
       What is a Software Architecture

      No one method of describing the architecture
       of a software system
      Several standard ways to look at the
       architecture of a system
         Design View
         Deployment View
         Implementation View
         Process View
      In this subject we are primarily looking at the
       Design view



CSE2200 - System Design and Implementation      Lecture 9
     Modeling a System’s Architecture


           Design view              Implementation view



                          Use case view


           Process view              Deployment view




CSE2200 - System Design and Implementation             Lecture 9
                 Architectural Views
      Design view
         the classes, interfaces and collaborations that form the
          vocabulary of the problem and solution domains
         comprised of class diagrams, interaction diagrams,
          package diagrams and state chart diagrams
      Process view
         the threads and processes which form the system’s
          concurrency and synchronisation mechanisms
      Implementation view
         the components and files used to assemble and release
          the physical system, the configuration management of
          the system releases
      Deployment view
         the nodes that form the system’s hardware topology on
          which the system runs


CSE2200 - System Design and Implementation                 Lecture 9
              Uni-SEP and Software
                  Architecture
                System Modelling

                                           uses


                  Architectural
                    Analysis                                 Solution Domain
                                                     uses
                                                                Modelling
                                                             uses   uses
                                   Architectural
                                      Design

                                                              Development
                                    uses          uses      uses Planning

Architect
                           Component Specification



CSE2200 - System Design and Implementation                                  Lecture 9
       A Uni-SEP Software Architecture

      Is a document that provides the context with
       which to develop the system
      Provides the long-term view of the growth of
       the solution to meet future business demands
      Provides a developer’s view of the system
      Partitions the system into manageable units
      Places constraints on the technology to be
       adopted in the context of the project goals




CSE2200 - System Design and Implementation   Lecture 9
             Architecture and System Modelling
                                                                                  Blasde
                                                                                           dadfaf        dsafa    asdfaf

                                                                                  adfaa


                                                                                  Blerbl
                      Architectural                                                 e                    Blerbl
                                                                                                           e

                          path
                                             Example Early Order Architecture
        Scenario 1
                                                (Fundamental Subsystems)
                                                                                                                           SA 3
                                                                                                                  V
                                                                                                    IF
Actor   Scenario 2                                                         SA 3                                   C
                                                                       V
                                         M
         Business     Object                   M
                                                                   C                                                       M
                                                                       M                                   M
         Scenario    Modelling
          Model                                                                                          SA 1          M   SA 2

                       path                     SA 2

                                         M                         M       M                                      IF
                                  SA 1
                                                            SA 1           SA 2


                                  Business Domain           Solution Domain         Architectural Solution
                                       Model                     Model          3rd or 4th Order Architectu
                                  (Subject Areas)      (Fundamental Subsystems) (Architectural Subsystems

                                              Timeline

        CSE2200 - System Design and Implementation                                          Lecture 9
        A good architectural approach
      will always be a view of the solution over the
       longer term
      allows pieces of the solution to be re-used
       and adapted
      allows existing technology to be re-used
      will always guide the development of a
       solution and the identification of development
       sub-systems and components
      is capable of illustrating how a solution is
       expected to deliver any functionality within its
       current scope as well as the future
       development possibilities
CSE2200 - System Design and Implementation      Lecture 9
           An Example Architectural
                 Approach

                          Presentation


     Infrastructure      Core Business       Administration
        Services            Model              Services


                       Communications


CSE2200 - System Design and Implementation           Lecture 9
          Example Architecture using
                  Packages
             Presentation                 Administration
                                            Services




            Core Business
                Model




               Infrastructure        Communications
                  Services




CSE2200 - System Design and Implementation                 Lecture 9
               Layered Architectures

      The most common form of software
       architecture used currently
      Defined as
         A software architecture that organises software in layers,
          where each layer is built on top of another more general
          layer.
         A layer can be loosely defined as a set of (sub)systems
          with the same degree of generality. Upper layers are more
          application-specific, lower layers are more general
      Refers to the design view of the system, not
       the dynamic behaviour of the system



CSE2200 - System Design and Implementation                 Lecture 9
        A typical layered architecture


                    Application systems


                     Business-specific


                        Middleware


                      System software



CSE2200 - System Design and Implementation   Lecture 9
                 The layers explained
    Application system layer
       contains one application system for each software system
        that offers a coherent set of use cases to some end-users
    Business-specific layer
       application-domain and business specific component
        systems that are for the particular business
    Middleware layer
       provides platform-independent distributed object computing
        and component systems for utilities
    System software layer
       contains the software for the computing and networking
        infrastructure, e.g operating systems, interfaces to hardware
        etc.
    No lower layer component should depend on a
     higher layer component
CSE2200 - System Design and Implementation                 Lecture 9
              An example of a layered
                   architecture
  Application                    Digicash
                                  Cashier

  systems          ATM Cashier                      Payment             Invoicing




  Business-                Money             Account         Invoice      Bank Customer
  specific               Management         Management     Management      Management




                             Java            HP ORB Plus
  Middleware

                        NT Workstation          TCP/IP
   System
   software

CSE2200 - System Design and Implementation                                          Lecture 9
              Advantages of layered
                 architectures
      Distinct interfaces can be defined for the
       layers aiding reuse
      Only components explicitly exported by the
       interface can be depended upon, thus
       reducing dependencies on internal volatile
       parts.
      Layered architectures are relatively easy to
       understand and explain
      They support distributed computing well (all
       current distributed computing standards are
       based on layers - CORBA and DCOM

CSE2200 - System Design and Implementation    Lecture 9
       Legacy Systems and Wrappers
 “Each of you, in turn, has told me how to reuse C++, if I’m
 a C++ programmer, Smalltalk if I’m a Smalltalk programmer,
 Lisp/Flavors if I’m a Lisp/Flavors programmer, Eiffel, if I’m
 a Eiffel programmer. Well, I’m someone who wants to be a
 C++ programmer but I happen to have a million lines of
 Fortran IV code which performs calculations on waveforms.
 How do I reuse my million lines of horrible, unmaintainable,
 nonextendible, working Fortran IV code in a C++ application?
 Don’t aske me to rewrite the Fortran code, because no one
 understands how it works and the author left the company
 15 years again”


CSE2200 - System Design and Implementation         Lecture 9
        Legacy Systems and Wrappers

      A legacy system is a pre-existing system that
       was created using other design methods and
       technologies, yet still manages significant
       business data and continues to support
       important business processes
      A wrapper is a piece of object-oriented
       software that encapsulates the legacy system
       and manages some interactions with it
      In many cases, businesses cannot afford to
       replace legacy systems, but also cannot
       afford to continue with the old methods


CSE2200 - System Design and Implementation    Lecture 9
       Example of Wrapping in UML
                                               <<component system>>
               <<component system>>          Bank Customer Management
                Account Management
                                                       Customer
                   Account




                                          <<component system>>
                                      Customer Account Management


                                                  <<wrapper>>

                                  <<interface>>          <<interface>>
                                  Account Data        Customer Information




                             Customer-Account
                             Transaction Manager




CSE2200 - System Design and Implementation                                   Lecture 9
                     Types of System

      Batch Transformation
         A sequential input-to-output transformation, in which
          inputs are supplied at the start, and the goal is to
          compute an answer
         Compilers, payroll programs, integrated circuit layout
      Continuous Transformation
         A system where the outputs actively depend on changing
          inputs and must be periodically updated
         Signal processing, windowing systems, incremental
          compilers
         Build architecture and classes around the operations in
          the system



CSE2200 - System Design and Implementation                 Lecture 9
                    Types of Systems

      Interactive Interface
         A system dominated by interactions between the system
          and external agents. The external agents are independent
          of the system, so their inputs cannot be controlled
         desktop applications, command languages for an
          operating
         Model-View-Controller (Observer pattern) is a good
          architecture for these systems
      Dynamic Simulation
         models or tracks objects in the real world
         economic models, video games
         Architecture needs to be strongly based upon real-world
          relationships


CSE2200 - System Design and Implementation               Lecture 9
                     Types of System
      Real-time Systems
         interactive system for which time constraints on actions
          are particularly tight or in which the slightest timing
          failure cannot be tolerated
         communication devices, device control (manufacturing
          robots)
         Architecture often forced to be very close to the hardware
          architecture
      Transaction Manager
         database system whose main function is to store and
          access information
         airline reservation systems, banking systems
         Architecture based on data structures and existing
          database model


CSE2200 - System Design and Implementation                 Lecture 9
                Client-Server Systems
      Two main types
         two tier
         three tier   Application               Application




                                               Business Server
                        Database             (Logical Data Model




                                             Database (Physical
                                                 Data Model)




CSE2200 - System Design and Implementation                         Lecture 9
                                    CORBA
       Non-standardised           Vertical domain-specific          Horizontal facilities
  application-specific objects             objects                        objects




                    Application           Domain             CORBAfacilities
                     interfaces          interfaces            interfaces

                            CORBA      Object Request Broker
                               CORBAservices interfaces




                                                                               Common
                                                                               Object
                                                                               Services


CSE2200 - System Design and Implementation                                     Lecture 9

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:10/27/2011
language:English
pages:55