Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Object Oriented Analysis and Design _Part 2_ - Lumba-Lumba Cerdik

VIEWS: 0 PAGES: 136

									    Object Oriented Analysis & Design
                With Visio




                 Dibawakan oleh
                Indra Sosrodjojo
1
             Indra@andalsoftware.com
    Analisis Application Domain

          Problem           Requirements
                                  for use          Application
           Domain                                    Domain
          Analysis                                  Analysis


                             Component
                Model         Design

                                         Specifications of
                                           components

                     Specifications of
                     architecture

                            Architectural
                              Design


2
    Application Domain


            User



                         Computerised
                           System
             User


                                        (Mathiassen et al, 2000)
             Application Domain

3
     Relative Stability of
     System Components

      Stable properties              Transient properties



      Model               Function              Interface

         Problem             Application
      Domain Analysis      Domain Analysis
    The relative stability is why we analyse the problem domain
      before the application domain.

4
    Aktivitas utama dalam
    Analisis Application Domain

        System Definition
        and model


                                   Interfaces
        Usage
                      Iterate


                       Functions
                                              Requirements
                                          (adapted from Mathiassen et al, 2000)

5
    Analisis Application Domain

     Activity           Content            Concepts
    Usage       How does system interact · Use Case
                with people and other    · Actor
                systems?
    Functions What are the system’s      · Function
               information processing    · Function type
               properties?
    Interfaces What are the target       · User interface
               system’s interface        · System
               requirements?               interfaces
                                         · Usage context
6
    Prinsip dari
    Analisis Application Domain

     Tentukan application domain dengan use cases.


     Kolaborasi dengan users.




7
    Usage Analysis




8
     Aktivitas utama didalam
    Analisis Application Domain
       System Definition
       and model


                                  Interfaces
       Usage




                      Functions
                                           Requirements
                                               (Mathiassen et al, 2000)

9
     Sub-activitas didalam
     Usage Analysis


      System definition
                                                       Use cases
                            Evaluate                   and actors
                          systematically


         Find actors
        and use cases                      Explore
                                           patterns


                                                      (Mathiassen et al, 2000)



10
        Actors dan Use Cases
      Actor: abstraksi dari user atau sistem lain yang berinteraksi
       dengan target sistem
          Actors adalah orang yang mengerjakan pekerjaan
      Use case: pola interaksi antara sistem dan aktor didalam
       application domain
          Ikuti proses bagaimana pekerjaan akan dilakukan




11
     Contoh Actor Table




12
       Actors vs Classes
       Use Cases vs Events
      Apakah actor sama dengan class ?
      Apakah use case sama dengan event ?
      Tidak! Class dan event ada didalam problem domain - sedangkan
       Actors dan use case ada didalam application domain.
      Apakah actors juga class didalam the model?
      Apakah events juga use case ?




13
     Dasar Usage Analysis
      Tentukan application domain dengan use cases.
      Evaluasi use case bekerja sama dengan users.
      Perhatikan perubahan organisasi yang dapat mengubah
       application domain




14
        Menentukan Actors dan Use Cases
      Berdasarkan pekerjaan dan pembagian pekerja
      Identifikasikan actors
        Perhatikan seseorang yang berperan dengan peran yang sama
        Terapkan pada sistem seperti pada orang atau user
      Menerangkan actor
        Masukan tujuan actor, karakteristik dan contoh
      Jelaskan use cases
        Gunakan statecharts dan atau dengan kalimat
        Buatlan sederhana dan tanpa detil yang tidak diperlukan



15
     Analisis Pekerjaan
      Perlu mengerti hubungan dari sistem pada application
       domain
          Pekerjaan apa yang ada didalam application domain?
          Bagiaman pembagian pekerjanya?
          Bagaimana pekerjaan yang berbeda dapat dihilangkan ?
      Jangan terlalu menekankan cara kerja sekarang
      Hasil utama adalah daftar yang lengkap dari pekerjaan di
       application domain




16
     Contoh Penjelasan tentang Actor
     Account Owner
      Goal: A person who owns an account. The account owner’s basic
       need is to make payments with their plastic card.
      Characteristic: The system’s users include many and very different
       account owners.
      Examples: Account owner A is insecure in the use of a plastic card
       as a form of payment. A only withdraws money from the ATM in
       emergency situations.
      Account owner B is technologically curious and uses the system
       often, optimally, and to the limit of its abilities.




17
       Contoh Statechart for ‘Cash
       Withdrawal’ Use Case
                              Prompt
     Insert                     for
      card                     code
              Card inserted             Awaiting code
                                     Enter code
                                                             Rejected
                                        Code entered

                               Code accepted             Cancel                  Payment


                                       Awaiting amount            Amount approved

                                       Choose amount                    Approve amount

                                                       Amount chosen
               Amount not approved
                                                                        (Mathiassen et al, 2000)
18
       Example Text Description for ‘Cash
       Withdrawal’
      Use Case: cash withdrawal is started by the account owner, when they wish to use
       their credit card to withdraw cash from an ATM. The account owner inserts their
       card into the ATM, and are then requested via the screen to type their PIN code.
       The screen will either show a polite denial, the card will be ejected from the ATM
       and the process will be canceled; or the screen will show a menu requesting the
       account owner to choose an amount of money by typing on the ATM’s keyboard. A
       new screen picture requests the account owner to approve the transaction. If the
       transaction is not approved the account owner is again requested to type an amount.
       Otherwise the use case ends by the ejection of the card, and the desired amount of
       money being paid.
      Objects: (to be added later)
      Functions: (to be added later)




19
     Use Case dan Struktur Actor
      Perlu menghubungkan use case dan actor satu sama lain
      Dapat dilakukan dengan ‘Actor table’, tetpai hanya
       untuk associations
      Dapat juga dilakukan dengan ‘Use Case Diagrams’
        Mempunyai actors dan use cases
        Gunakan structure untuk menghubungkan antara actor seperti
         pada ‘Class Diagram’




20
     Contoh Actor Table




21
         Groups of Use Cases
                          Deposit
     Customer                              Bank employee involved in
     involved in all    Get customer
                         information
                                             2 of 3 deposit use cases
     deposit use
     cases                 Deposit
                                            Loan
                                                           Bank Employee
                       Cash withdrawal   Establishment



          Customer                         Maintain      Bank employee
                                                           involved in all
     Customer involved in only            Payments       loan use cases
     payment loan use case
22
     Explore Use Case Patterns
      The procedural pattern
          General pattern for insuring that steps in a process or a
           sequence of rules are followed
      The material pattern
        General pattern when there are few rules to follow, i.e. actions
         can be taken in any order
        May possibly have some small action sequences specified as side
         patterns




23
     Pola Procedural

               action 1

          State 1           Can’t do action 2 unless
                            action 1 is already done
               action 2




          State n

               action n+1




24
         The Material Pattern
                                          Actions 1 & 2 can be
                       start action       done in any order
     Material pattern is
                                                 action 1
     for ‘artisan like’
     materials that can be                       action 2
     manipulated in any
                                General
     desired order.              State           Process n
     E.g. diagrams, text,
     drawings being
                                                Process n+1
     constructed.

                        final action              Processes must be
                                                  completed before returning
                                                  to general state
25
     Evaluate Systematically
      Carefully study descriptions for mistakes and inconsistencies.
      Test use cases to see if true in practice, e.g. using prototypes
       to experiment.
      Evaluate the social changes in the application domain.




26
     Evaluation Criteria
      Use cases should be simple, constitute a coherent whole.
      The description of actors and use cases should provide
       understanding and overview.
      Use cases should be described in enough detail to enable
       identification of functions and interface elements (our
       next topic in application domain analysis!).




27
     Experimenting with Prototypes
      Notation of use cases doesn’t allow successful verification by
       the users
      Construct experiments so that
          Use future users for testing
          Make environment as realistic as possible
      Be sure to follow five phases covered earlier: planning,
       development, preparation, test, and summarising




28
        Principles of Usage Analysis
      Determine the application domain with use cases.
        Need cooperation between users and developers.
        Both an analytical and a creative activity.
      Evaluate use cases in collaboration with users.
        Best way is with prototypes.
        Can be paper and pencil exercises.
      Assess social changes in the application domain.
        Rethink the business processes.
        Avoid work-related problems and unnecessary human adjustments.




29
     Tutorial: Usage Analysis
      Individually, brainstorm a list of use cases and actors for the
       Paul’s Pools example.
      As a class, compare and discuss your lists and agree on a
       refined list.
      Identify which use cases are performed by which actors.
      With the rest of the class, choose one use case and specify it.




30
     Function Analysis




31
Aktivitas utama didalam
Application Domain Analysis

            System Definition
            and model


                                       Interfaces
             Usage




     Next, we’ll look      Functions
     at this activity                           Requirements
                                                    (Mathiassen et al, 2000)

32
      Functions

     “A facility for making a model useful for actors.”
      Express the intent of the system
      Express what is going to happen, but not how
      Need to find the right level of detail,
        Too general is too uncertain
        Too detailed is inefficient
        Inexperienced developers need more detail



33
     Sub-activities didalam
     analisa Function


             System
             Definition                Evaluate
                                       critically
                 Find
               functions
                            Specify
                            complex
                           functions                Function list
      Use Cases




34
     Contoh Function List




35
         Tipe dari Functions
                                                I    F M                  I     F M
        Ada 4 tipe function utama     AD                     AD
                                            *
        Tipe Function : Kalsifikasi                                               *
         dari suatu function
                                       PD *                   PD
         berdasarkan interaksi                  Update                        Signal
         antara component dan                   I    F M                  I     F M
                                       AD                     AD
         context dari sistem                *                      *


                                       PD                     PD
                                                    Read                      Compute
                                                         Effect of processing
                                                       * Initiative
36
     Mencari Functions
      Mencari functions dengan memeriksa classes, events,
       and use cases
      Analisis secara sistematis dengan menggunakan empat
       tipe function
      Hasil dari sub aktivitas adalah daftar kebutuhan function
       dari system
      Termasuk didalamnya name, type, dan assessment dari
       kompleksitas dari setiap function : simple, medium,
       complex, or very complex



37
       Update Functions

                       I   F M                How is the event observed and
            AD
                 *                             registered? In which use cases?
                                              How can the use cases be
                                               supported by updating functions?
            PD *                              Which objects, attributes, and
                       Update
                                               structures are affected by the
      Activated as a consequence of an
                                               event? What requirements for
                                               update functions?
       event in the problem domain
      Results in a change in the state of
       the model


38
       Read Functions

                      I   F M                What do the actors need to
            AD
                 *                            know about the state of the
                                              model (represents the problem
                                              domain)?
            PD
                       Read                  About which objects and
                                              structures in the model do the
      Activated by a need for                actors need information?
       information by an actor               What ‘readings’ do these give
      As a result, computerised system       rise to?
       displays parts of the model to the
       actor

39
       Compute Functions

                     I    F M              Which computations, not
           AD
                *                           necessarily based on the model,
                                            do the actors need to have
                                            carried out?
           PD                              Does the computational basis
                         Compute
                                            come from the actors, the
                                            model, or both?
      Activated by a need for
                                           Which computations form
       information by an actor              complete wholes in the use
      The computerised system              cases?
       computes and displays results to
       the actor

40
      Signal Functions
                   I   F M              What are the critical states for the
         AD                              model?
                                        What is their significance? What
                          *              are the consequences when they
         PD                              occur?
                   Signal
                                        How should the function identify
  Activated by a change of state in
                                         that a critical state has been
   the model
                                         reached?
  Results in either displaying the
                                        How should the signal be reported
   signal to the actors or
                                         to the AD or PD? How reliable and
   automatically intervening in the
                                         strong?
   problem domain

41
     Example Function List




42
     Menentukan Complex Functions
      Yang termasuk complex function melibatkan beberapa tipe
       function
      Beberapa format :
        mathematical expression
        algorithm in structured language
        functional partitioning in the function list




43
        Contoh
        Algorithmic Specification

     Query possible reservations:
       given time or date or employee-name
       search objects in time period-available and select those
          who belong to employee-name, if known
                  have date, if known
                  cover point in time, if known
       result objects of time period-available that fulfill the
          criteria


44
     Contoh Functional Partitioning




45
        Evaluate Systematically
      Work with the function list itself
        Functions must be mutually consistent
        Each function must be at an appropriate level of abstraction
      Ensure total functionality is consistent with the list
        prototype the usage - experiment
        review questions above for each type of function
        compare with system definition and models
      Ensure functions are not to general/vague or too detailed




46
       Prinsip dari analisis Function

      Identify all functions.
          A complete list is very important
      Specify only complex functions.
      Check consistency with use cases and the model.
          Checking this can reveal insufficient analysis




47
     Interface Analysis




48
       Aktivitas utama dalam
     Analisis Application Domain
        System Definition
        and model


                                   Interfaces
        Usage




                       Functions
                                            Requirements
                                                (Mathiassen et al, 2000)

49
     Terminologi
      Interface: Fasilitas yang membuat model sistem dan function
       dapat berinteraksi dengan actors.
      User interface: Interface untuk users.
      System interface: interface ke sistem lain.
      Usage context: The application domain characterized by actors
       and use cases.




50
     User Interface
      Are very important: they can make or break system use
       and benefit realisation.
      Needs to carefully fit the usage context.
      Need to be designed carefully - small details multiply
       difficulties with usage.
      Need to account for the different kinds of users with
       different skills and capabilities.
      Very difficult to design without feedback -generally must
       be tested with users.


51
     Systems Interface(s)
      May need interfaces for non-human actors, i.e. other
       systems
      Not commonly used for administrative systems
      More common for monitoring & control systems
          direct sensors in the environment - e.g. temperature
          direct intervention, e.g. motors, switches
          may also input or output from other computer systems
      Need to design and make sure that these technical
       connections can be realised




52
     Sub-activities in
     Interface Analysis
                  Function
                  list

       Class
       diagram                                Explore
                                              patterns

                    Determine
                     interface
                     elements                   Describe interface
                                                   elements


                         Evaluate interface
      Use cases                                              Description of
                             elements
                                                             interfaces


                                                           (Mathiassen et al, 2000)

53
        Tailor Usability to Context
      Usage is relative to usage context




54
         Study the Usage Context
      Study both human actors and use cases
        Does the individual user solve several tasks in parallel?
        Does the user move physically while working?
        Is the work often interrupted?
        Are certain use cases significantly different from the typical use
         cases?
        Do certain work tasks require a quick response from the
         computerized system?
        How is it ensured that the users notice when the computerized
         system performs a signal function?


55
        Explore User-Interface Patterns
      A user interface usually mixes several patterns or styles
      Four main patterns/styles
          menu
          form filling
          command language
          direct manipulation
      (also natural language)




56
      Menu Selection

      Advantages                      Disadvantages
        Shortens learning               Risk of too many menus
        Reduces key-strokes             Slows the frequent user
        Structures decision making       down
        Allows easy support of          Consumes screen space
         error handling                  Requires rapid display rate
        High level tools allow for
         easy programming



57
      Form Filling

      Advantages                      Disadvantages
        Simplified data entry             Consumes screen space
        Requires modest training
        Makes assistance
         convenient
        High level tools allow for
         easy programming




58
      Command Language

      Advantages Flexible           Disadvantages
        Appeals to “power” users      Poor error handling
        Supports user initiative      Requires extensive training
        Convenient for creating
         user-defined macros




59
      Direct Manipulation

      Advantages                      Disadvantages
        Immediately visible result      Effort required to develop
         of interaction                  Difficult to invent
        Useful for both casual and       meaningful icons, symbols,
         frequent users                   etc., unless can rely on
        Can be extremely efficient       standard objects




60
        Dialog Style: Function-Oriented vs
        Object-Oriented

      Is the interface primarily based on functions or objects? Need
       both, but which choose first?
          I.e., does the user choose the function first, then choose the object or
           vice versa?
      Function-oriented dialogues are better for routine,
       automated work
      Object-oriented ones are better for varied individual work
       tasks as they give more flexibility
          But, usually require more development time and effort

61
     Some Guidelines
      A dialogue needs to be simple, natural, and consistent.
      Requirements placed on the users’ memory need to be
       minimal.
      Feedback must be informative and constructive.
      Errors must be prevented.
      Detailed discussion is beyond the scope of this unit.




62
         Determine User-Interface Elements
      Representations of objects in the model
        Many possibilities: icons, fields, tables, diagrams, windows
        Need a clear & consistent system of representations
      Activation of functions
        Buttons, menu screens, pull-down/pop-up menus
        Also need support for visualisation and feedback
        Needs to be consistent and fit within the dialog pattern/style
      Result is a list of user-interface elements




63
     Describe Interface Elements
      User Interface:
        General effect: colours, fonts, types of menus, types of icons,
         default positions
        Navigation: dialog linkages between buttons, menus, screens,
         windows, etc.
        Computer screens/windows/forms, etc.: layout, interactivity,
         consistency
        Outcome of activity is screen/form designs, navigation diagram
         and other descriptions




64
     Example Navigation Diagram
     (Partial)

 Start                                 Exit

                                  Commands,
 Miniature                        menu
 of screen                        selections,
 or window                        or buttons to
                                  change
                                  screens
                                  or windows



65
        Evaluate the User Interface
      A User Interface cannot be constructed bottom up without
       experiments using prototypes.
      Should be a carefully controlled process using the five sub-
       activities.
      Planning needs to lead to concrete evaluation and quick
       development with efficient tools.
      Preparation needs to determine how collaborate with users,
       ensure realism, and select good example tasks that enhance
       feedback.
66
     Explore Systems Interface Patterns
      Consider what/how data should be sent to and received
       from other systems (if any)
      Other systems may be
        simple external devices: sensor, switch, or motor use simple
         read or activate device patterns
        complex computer systems: need a communication protocol
         which may be supplied or need to be designed




67
       Read External Device Pattern
        Read either regularly or dependent on an event



                          Device                  Memory
                       state                    time
      connection to                  1      1
                                                value
     external device
                       read                     measurement
                                                latest-value
        Memory object can just be the model object




68
     Interaction Protocol
      A protocol defines command facilities supporting the
       possible use cases for a system by another
      Is agreed upon by designers of the two systems (unless
       one has already been designed/built!)
      Specify a pattern for interaction using a list of commands
       for each side and their expected responses
          Separate protocol item named for each command
          E.g. Request some info or Prepare to accept info
          Commands may check the state of the other system



69
     Determine and Describe the
     Systems Interface Elements
      What other computer systems will the system be
       connected to and exchange information with?
          What protocol(s) will be needed?
      Will the system be connected directly to the problem
       domain through external devices?
          What external device read or write interfaces are needed?
      Result is a list and specification of each.




70
     Evaluate System Interfaces
      Protocols can be tested on pencil and paper by working
       through use cases
      Ultimate test is that the physical connections actually work
        If there is any doubt, these connections need to be tested as
         early as possible
        Build and test technical feasibility prototypes




71
     Principles of
     Interface Analysis
      Tailor usability to the application domain
          need to know who the users are and in what situations the
           computerised system will be used
      Experiment and iterate
        interfaces are complex and interact with users in ways that can’t
         be anticipated
        experiments need to be planned, efficient, and realistic - and
         likely will be repeated




72
     Principles of
     Interface Analysis (2)
      Identify all interface elements
        Important not to leave anything out!
        Details can be supplied/determined later, as long as the basic
         structure is clear and coherent




73
     Learning Objectives
      Understand the basics of how to determine a strategy for
       using OOA&D
      Understand what & how documentation should be produced
       during OOA&D
      Understand what makes good analysis documents and good
       design documents




74
     Concrete Project Strategy
     Formulation
      Development methods provide advice and ideas for
       work practices on an actual (or concrete) system
       development project
      Good, efficient development work requires that effort is
       concentrated on the most difficult task
      To do so, you must determine a strategy that identifies
       and deals with the most difficult task, and reconsiders
       the strategy as the project progresses



75
     Terminology
      Requirement: A system’s externally observable behavior
      Conditions: The technical, organisational, and human
       opportunities and limits involved in solving a task
      Strategy: A general approach for performing a task




76
     Principles
      Tailor the strategy


      Identify the difficult requirements and conditions


      Maintain degrees of freedom




77
     Sub-activities in Strategy
     Construction

     Existing
     documentation


                            Formulate               Analysis and
                             strategy               design strategy
      Characterise
        the task                        Guiding



             Evaluate                     Object-oriented
             difficulties               analysis and design


78
         Characterise the Task
      Problem domain: Are you familiar with the type target system?
      Application domain: Are you familiar with the user organisation?
      Technical platform: Which technology will the system be implemented
       on?
      Project organisation: How qualified are the developers? How good are
       the development conditions?
      Special aspects: Which special conditions apply to this task?
     Use the checklist in the text as inspiration for factors to consider.




79
     Evaluate Difficulties
      How great are the difficulties related to analysis of the
       problem domain?
      How great are the difficulties related to analysis of the
       application domain?
      How great are the difficulties related to the design of the
       system’s architecture?
      Use the checklist in the textbook as inspiration for ratings
       areas.




80
     Design the Strategy
      Put highest emphasis on areas with great difficulty.
      Initiate activities in areas with great difficulties early in the
       process.
      Make critical decisions first and less critical decisions later in the
       process.
      Design the strategy to ensure coordination of decisions.
      Include requirements management in the strategy.
      Possibly affect the conditions for the development in order to
       enable a satisfactory strategy.
     Result is a project plan including all of the above.



81
     Principles of
     Strategy Construction
      Tailor the strategy
        Relate the requirements to the technical and organisational
         realities.
      Identify the difficult requirements and conditions
        Arising from disparities in the above.
      Maintain degrees of freedom
        Other problems are inevitable, so preserve breathing space.




82
     Dokumentasi




83
     Terminologi
      Analysis document: Presentasi yang logis dari hasil analisis
        Dapat dijadikan sebagai dasar perjanjian
        Dapat dijadikan acuan pada saat implementasi
      Design document: Presentasi yang logis dari hasil design
          Dapat dijadikan acuan pada saat implementasi




84
     Pentingnya
     Analysis Document
      A work tool in which sub-results can be collected and structured
       as they are produced.
      A control tool that can be used to decide if the analysis work
       progresses sensibly and actually leads to determination of the
       requirements to the computerized system.
      A basis for the customers’ and the users’ decision about whether
       they want the outlined computerized system at the expected cost.
      A baseline for the ensuing work with design and realization.




85
         Pentingnya
         Design Document
      A work tool in which design decisions can be collected and structured
       as they are made.
      A control tool to measure the progress of the design work. Does the
       document still contain essential uncertainties in relation to the
       conditions for the system’s realization?
      An agreement tool that retains the agreement about the computerized
       system’s design. It should retain agreements between the designers
       during the design work, which should communicate all essential
       decisions to the developers who will realize the system.




86
     Dokumentasi yang Baik
      Harus ditulis dengan bahasa umum, dan tatabahasa yang
       baik serta jelas
      Dapat dibuat dengan menambahkan gambar, daftar dll
          Gambar dan daftar tidak berdiri sendiri tetapi tidak perlu
           dijelaskan terlalu detil.
      Dokumentasi harus singkat tetapi jelas
        Jangan menulis program untuk programmer atau desain untuk
         desainer




87
     Prinsip
     Domukentasi
      Use technical prose supplemented by formalisms.
        Should be concise and of high quality
        Should only describe the essential
      Retain results and decisions continuously.
        Create documentation along the way to ensure quality and
         make progress visible
      Chart progress through documented results.
        Documentation provides a basis for measurement




88
                          Phases of OOA&D

     System Choice                  Problem             Requirements
                                                              for use           Application
     (Pre-analysis)                 domain                                       domain
                      System        analysis                                     analysis
                     Definition

                                                          Component
                                              Model         design

                                                                      Specifications for
                                                                        components         Now concerned
                                                 Specifications for                        with this area of
                                                 architecture
                                                                                                activity and
      (adapted from Mathiassen et al, 2000)
                                                        Architectural                            its product
                                                           design


89
     Dua bagian dari Architecture
      Component architecture: struktur sistem yang terdiri dari
       componen yang saling berhubungan
      Process architecture: Struktur eksekusi dari sistem terdiri dari
       interdependent processes




90
      Component and Process
      Architectures

     Component Architecture:          Process Architecture
        Classes                         Objects
        Stable aspects                  Dynamic aspects
        Related components              Coordination of processes
        Logical level                   Physical level
        Structure for descriptions      Structure for execution




                                                             (Mathiassen et al, 2000)

91
     Design of Architecture




92
         Prinsip
         Architectural Design
      Define and prioritise criteria.
          various criteria besides the functional requirements
      Bridge criteria and technical platform.
          meet criteria by making use of technical facilities
      Evaluate designs early.
          eliminate ambiguity early to enhance productivity




93
        Some Good Design Qualities
      The system models the parts of the problem domain that
       were agreed upon.
      The system’s functions correspond to the requirements
       from the application domain.
      The interface implements the described interaction.
      The technical platform is used effectively.
      The system can be adapted to new requirements and needs.



94
     Design Criteria
      We don’t judge just by how well a system meets
       criteria; not meeting one criterion can be critical
                A good design has no major weaknesses
                A good design balances several criteria
     Criterion: A preferred property of an architecture
      Need to define priorities among criteria and evaluate
       them




95
     Component Architecture




96
        Terminologi
      Component Architecture: Struktur sistem yang terdiri dari
       component yang saling berhubungan
      Component: Kumpulan dari bagian program yang keseluruhan
       proses terdefinisi
        Seperti cluster
        Terdiri dari classes dan atau components lain




97
     Prinsip
      Reduce complexity by separating concerns
          Aids comprehendibility, maintainability
      Reflect stable context structures
          Interface at the top, model at the bottom
      Reuse existing components
        Reduces development effort
        Improves design comprehensibility




98
     Sub-activities in Component
     Architecture Design

                         Explore architectural
                               patterns
      Criteria

                                                   Identify
              Define
                                                 components
            subsystems

                                                              Component
                                     Class diagram            specification


                     Use patterns and
                       components
                                                          (Mathiassen et al, 2000)

99
      Explore
      Architectural Patterns
       Patterns are a useful guide to design
       Some patterns have been proven useful
           Layered architecture
             idea is from the ISO OSI network model
           A generic architecture
             from the authors
             based on the Model Function Interface framework
           Client-server architecture
             should consider whenever distribute a system




100
      Layered Architecture

              «component»
               Layer i+1

                             Upward interface

              «component»
                Layer i

                             Downward interface
              «component»
               Layer i-1
101
         Generic Architecture
      «component» Interface

                     «component»                       «component»
                    User Interface                   System Interface

                                       «component»
                                        Function


                                       «component»
                                         Model

      «component» Technical platform

             «component»               «component»           «component»
                  UIS                     DBS                    NS
102
      Generic Architecture (2)
       Can further divide functions into two kinds and group into
        components differently
         Task-related functions
         Model-related functions
       Can split functions, or place some with model component
       For very simple system, may not need the function
        component at all




103
      Client-Server Architecture

       «component»   «component»   «component»
         Client1       Client2       Clientn




                     «component»
                       Server

                                        (Mathiassen et al, 2000)

104
      Client-Server Architecture (2)
       Components are a server and a number of clients
       Server provides a collection of operations (or services!) to
        the clients
       Clients use the server independently
       Potentially a good architecture whenever distribute a
        system geographically
       Need to decide form of distribution of system’s parts
        between client and server


105
      Five Forms of Distribution




                                   (Mathiassen et al, 2000)

106
      Define Subsystems
       For large systems, often need to split the system into
        subsystems
       Allows division of work so that design and building of
        subsystems is independent (except for any interfaces
        between them)
       Each subsystem may be a system in its own right, with
        interface, function, and model components
       Must design the architecture of each subsystem



107
          Example Subsystems and
          (Sub)system Interfaces

 «component» Subsystem A                   «component» Subsystem B


       «component»           «component»      «component»            «component»
      User Interface    System Interface   System Interface      User Interface


                «component»                             «component»
                  Function                               Function


                «component»                             «component»
                     Model                                  Model



108
         Identify Components
       Design the architecture for each system or subsystem by breaking
        into components
         Begin with 3-tiered architecture or a pattern
         Extend basic architecture by examining model, function, and
          interface design concerns
         Extend further by finding useful existing components
         Generally good to encapsulate the extended technical platform




109
       Model Design Concerns

       Responsibility:   The problem domain model
                          Incohesive or complex
       Contextual          problem domains
        issues:           Accounting, reservations,
       Exemplars:          inventory, administration
                          Databases

       Special needs:

110
         Function Design Concerns
       Responsibility:    The functionality on the model
                           Need for incohesive or complex
       Contextual issues:  functionality
       Exemplars:         Payroll, signal processing,
                            cruise control
       Special needs:     Model-related functions,
                            application-related functions,
                            cryptography

111
         Interface Design Concerns
       Responsibility:    Interaction between functions
                             and actors
       Contextual issues: Incohesive or complex actors or
       Exemplars:           usage
                           Browsing, games, presentation
       Special needs:       monitoring
                           Screens, windows, buttons,
                             print-outs, devices,
                             communications
112
      Using Components
       Can obtain and use components from a number of sources
         Another existing system
         Earlier version of system
         Standard purchased components - software library
       Need to encapsulate these to limit impact if later change
        chosen components




113
         Specifying Components
       Complex components should be specified in detail.
       May attach supplemental notes to class diagrams.
       Good to summarise each component’s
         Responsibility (service it provides)
         Dependency (on other components)
         Relationship to the system context




114
      Review of Principles
       Reduce complexity by separating concerns
           Aids comprehensibility, maintainability
       Reflect stable context structures
           Interface at the top, model at the bottom
       Reuse existing components
         Reduces development effort
         Improves design comprehensibility




115
Application Domain Analysis in Context of
OOA&D Activities

                                  Analysis of           Requirements
                                                              for use           Analysis of
                                   problem                                      application
                                   domain                                        domain


                                                          Design of
                                              Model      components

                                                                      Specifications for
                                                                        components

                                                 Specifications for
                                                 architecture

                                                         Design of
      (adapted from Mathiassen et al, 2000)             architecture


116
       Component and Process
       Architectures

      Component Architecture:          Process Architecture
         Classes                          Objects
         Stable aspects                   Dynamic aspects
         Related components               Coordination of processes
         Logical level                    Physical level
         Structure for descriptions       Structure for execution




                                                               (Mathiassen et al, 2000)

117
      Process Architecture




118
      Main Activities in
      Architectural Design

             Analysis
             document              Component
                                   architecture

                  Criteria



                             Process
                             architecture     Architectural
                                              specification
                                                  (Mathiassen et al, 2000)

119
         Introduction
       Now concentrate on objects and their involvement in
        processes
       Need to coordinate when have multiple processes with
        shared resources
           Processors
           Program components
           External devices
       Results:
         Deployment diagram showing processors, assigned components,
          and active objects
         Outline of solutions for coordination mechanisms

120
         When & Why
       Not a significant activity for a simple system with a single
        process, e.g. a stand-alone system
       Critical for large systems, especially monitoring and control
        systems, & embedded systems
       May wait to begin this activity until component architecture
        and components are nearly complete
       May start this activity early with exploratory and
        experimental work, which heavily influences components



121
      Terminology
       Process Architecture: A system-execution structure
        composed of interdependent processes
       Process: A collection of operations that are executed in a
        bounded and linked sequence
       Processor: A piece of equipment that can execute a program




122
      Terminology (2)
       Program Component: A physical module of program code
       Active object: An object that has been assigned a process




123
        Processes, Active Objects, and
        Shared Objects
                                Object 1     Potential conflict   Object 3
      Process                   o1           over shared          o5
      1                                      program
                                o2           component            o6

                                                   Object 2
                                                   o3
                                       Process 3
                                Object 4           o4             Object 5
      Process 2                 o7                                o9

                                o8                                o10
            Active object                      Process 4
            because it starts
            a new process
124
      Concurrency
       True concurrency: When two or more events in the system’s
        context can occur at the same time and processes must
        support this (e.g. multiple users)
       Random concurrency: When two or more operations are
        designed to be executed at the same time (e.g. print in
        background)
       Don’t have any choice about the former




125
      Principles
       Aim at an architecture without bottlenecks
           would slow down the system and cause problems
       Distribute components on processors


       Coordinate resource sharing with active objects




126
        Sub-activities in
        Process Architecture Design
          Class diagram and
          component specifications

                              Identify shared
                                 resources

              Distribute program
                                               Select
                 components
                                            coordination     Deployment
                                            mechanisms        diagram

      Explore distribution
                                                  Explore coordination
           patterns
                                                        patterns

127
      Distribute Program Components
       Different components need to be placed on individual
        processors
       First, separate out any active objects from passive program
        components
       Second, determine the available processors
       Distribute the program components and active objects onto
        the processors




128
      Explore Distribution Patterns
       Patterns for how components are placed on processors
         The centralised pattern: Centralised data and functionality, thin
          client, but low robustness
         The distributed pattern: Replicated data, server only broadcasts
          updates, robust, but potential data inconsistencies
         The decentralised pattern: Partitioned data, low
          inconsistencies, more diversity/complexity




129
         Identify
         Shared Resources
       Processor: Two or more concurrent processes that should be
        executed on the same processor
       External Devices: Two or more concurrent processes use the
        same external device
       Component: Two or more concurrent processes call operations
        on objects in the same component




130
       Example Deployment Diagram:
       Airline Check-in
                  Active objects




      Processor                    External
                                   devices
                                    (Mathiassen et al, 1999)
131
      Finding Bottlenecks
  Processors: What is the relationship between the capacity of each
   processor and the needs of the active objects assigned to it?
  External Devices: What is the accessibility, capacity, and load of the
   different external devices in the interface?
  Data Storage: Which parts of the model need to be stored on which
   storage media?
  System/Network Connections: What is the capacity and load of the
   system’s connections?



132
      Overcoming Bottlenecks
       Two options:
         Change the design and the distribution of the components onto
          the available processors
         Enhance the platform with more processors or more powerful
          processors




133
      Select
      Coordination Mechanisms
       Many operating systems and technical platforms provide
        mechanisms to control sharing
         Varies substantially from platform to platform
         So need to be sure in each case!
       If not, we have to solve it ourselves by developing our
        own coordination mechanisms
           Generally rely on active object that controls the sharing
           Can make use of generic patterns




134
          Coordination Mechanisms
       Generalised patterns of coordination:
         Dedicated monitor ensuring atomic access to shared resources.
         Centralized task dispatching for coordination of all concurrent
          processes. (e.g., event loop)
         Subscription to state changes for initiation of processes in
          opportune situations.
         Asynchronous exchange of data to avoid unnecessary delays with
          read and write operations.




135
      Prinsip
      Architecture Design
       Aim at an architecture without bottlenecks
           Slows down the system and causes problems
       Distribute components on processors
           Decision can reduce potential bottlenecks
       Coordinate resource sharing with active objects
           Use the technical platform or design your own mechanisms




136

								
To top