CSC407 Software Architecture Winter 2007 The ICONIX Process by badboyben

VIEWS: 10 PAGES: 23

									CSC407: Software Architecture
        Winter 2007
   The ICONIX Process

            Greg Wilson
             BA 4234
      gvwilson@cs.utoronto.ca

                                1
Architecture Follows Process
• Good organizations know what their
  process is
  – So that they can repeat their successes
• ICONIX is a “lite” version of Rational
  Unified Process (RUP) and its kin
  – The bigger the project, the more formalism you
    need

                                                     2
GUI Prototype
                        Roadmap           Sequence
                                           Diagram

                 Use Cases

                             Robustness
                              Diagram




        Domain
         Model




                                 Class
                                Diagram
                                          Code
                                                 3
How to Get From Uses Cases to
Code?
GUI Prototype



                Use Cases




                            ?

                                Code




                                       4
Work Backwards
• We need a complete set of classes, with
  accompanying attributes and methods
  – So we need design-level class diagrams
• Before we have methods, we need to
  allocate behavior to classes
  – So we need sequence diagrams for the use cases



                                                 5
                    …Work Backwards
• Before we do sequence diagrams, we need
  to know which objects are involved in
  which use cases
  – Get this information from robustness diagrams
  – Which are produced by robustness analysis
  – Which is not part of the UML standard, but is
    very useful


                                                    6
                    …Work Backwards
• Before we can do robustness analysis, we
  need a domain model
  – Need this anyway so that we can be sure we
    understand the customer’s view of the world
• So now let’s work forward




                                                  7
Step 1: Requirements
• Identify real-world domain objects and the
  relationships between them
• Prototype a GUI
• Identify use cases
• Milestone 1: requirements review



                                               8
Step 2: Analysis
• Write use cases
• Perform robustness analysis
  – Identify objects used in each use case
  – Update domain model
• Milestone 2: preliminary design review



                                             9
Step 3: Design
• Identify messages sent between objects
• Finish turning domain model into class
  diagram
  – Add visibility, member variables, etc.
  – Decide relationship types
• Milestone 3: detailed design review


                                             10
Step 4: Delivery
•   Write unit tests
•   Write code
•   Perform integration testing
•   Milestone 4: deployment




                                  11
GUI Prototype
                      Requirements Revisited
                 Use Cases
                             • Sometimes called the
                               "discovery" phase
                               – Discover what the
                                 customer wants
        Domain
                               – Discover how the
         Model                   system wants to be built
                             • Goal is to build a
                               coherent vocabulary
                                                        12
Grammatical Discovery
• Simplest way to get started is grammatical
  discovery
  – Interview customer (or read email archive)
  – Nouns become objects, verbs become methods
• Don't spend too much time in this phase
  – Even on a large project, a few days is plenty of
    time to evolve a problem-specific language that
    you can use for the rest of the work
                                                   13
What To Look For
•   Duplicate terms
•   Which objects interact directly with which
•   Which objects generalize which
•   Which objects "own" or "contain" which
    – Worry about multiplicity later
    – But make a note if a relationship has properties


                                                     14
Domain Modeling Errors
• Don't assign multiplicities early
• Dont' try to do use cases, domain modeling,
  and GUI prototyping independently
• Don't worry about using generics, relational
  database tables, etc., at this stage
• Don't try to impose design patterns


                                             15
Analysis Revisited                       Sequence
                                          Diagram

            Use Cases

                          Robustness
                           Diagram




   Domain
   Model                • Bridge between
                          analysis and design
                        • What does each thing
                          actually do?
                                               16
Purpose of Robustness Analysis
• Sanity check on use cases
• Completeness check: are all alternative
  cases accounted for?
• Ongoing discovery of objects
• Preliminary design



                                            17
Three Types of Objects
• Boundary objects are things that actors
  (e.g., users) interact with
  – Windows, dialogs, etc.
• Entity objects are long-lived data
  – Typically mapped to database tables
• Control objects contain the application's
  intelligence
• Yes, this is Model-View-Controller…
                                              18
  Drawing Robustness Diagrams

                           Allowed
Boundary object




 Entity object




 Control object
                       Not Allowed
                                     19
Interaction Analysis
• Robustness analysis told us which objects
  talk to which
• Interaction analysis tells us what they say
• Translate use cases into sequence diagrams
  – Translation can't be done directly if we don't
    know what objects we have



                                                     20
Sequence Diagram Format
• Each sequence diagram should contain:
  –   The text of the use case
  –   Objects (use the robustness diagram icons)
  –   Messages (arrows between lifelines)
  –   Method names (labels on arrows)
• Advanced tools can produce these semi-
  automatically

                                                   21
How To Tell If It's Right
• Does it meet the first lecture's criteria?
   – Single Responsibility Principle
   – Liskov Substitution Principle
   – Law of Demeter
• This is the time to use collaboration
  diagrams and state diagrams
   – If you're going to use them at all…

                                               22
                                        Sequence
                                         Diagram
Classes and Code
• After all this, the final
  design and coding are
  straightforward
   Domain
    Model




                               Class
                              Diagram
                                        Code
                                               23

								
To top