Information Systems Analysis and Design Implementation Concerns, Review - PowerPoint PPT Presentation

1 / 38
About This Presentation
Title:

Information Systems Analysis and Design Implementation Concerns, Review

Description:

Mapping Designs to Code. Mapping the structure of classes and methods to source code can be fairly ... data types such as hash tables or array lists ... – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 39
Provided by: gle9
Category:

less

Transcript and Presenter's Notes

Title: Information Systems Analysis and Design Implementation Concerns, Review


1
Information Systems Analysis and
DesignImplementation Concerns, Review
  • INFO 620
  • Glenn Booker

2
Rational Unified Process
  • We have already discussed the Use Case Model,
    Domain Model, and Design Model for the RUP
  • The final model is the Implementation Model,
    which includes the code needed to implement the
    software

3
Rational Unified Process
  • During analysis and design, prototypes may be
    made to help understand requirements and guide
    design choices, but these prototypes may or may
    not become part of the final product
  • Realize that implementation is often much more
    iterative than presented here

4
Iterative Development
  • The RUP is designed to accommodate iterations
    based on use cases, so that the core functions
    are often developed fully first, then additional
    functions are added in later iterations
  • Early iterations may influence later analysis and
    design activities

5
CASE Tools
  • Some Computer Aided Software Engineering (CASE)
    tools can generate code automatically from design
    drawings
  • Some can also reverse engineer existing code
    input source code and determine design drawings
    from it

6
Defining Classes and Objects
  • Classes may be declared using the
    formatvisibility class classnamewhere
    visibility private,protected,public
  • Objects or attributes are declared
    usingvisibility datatype objectnamewhere
    datatype is integer, text, etc.
  • Parameters are declared usingdatatype
    parametername

7
Mapping Designs to Code
  • Mapping the structure of classes and methods to
    source code can be fairly mechanical
    implementing the methods is often the greatest
    challenge
  • Most classes are defined as publicpublic class
    SalesLineItem
  • Most attributes are privateprivate int quantity

8
Mapping Designs to Code
  • Reference attributes are also often private
  • In SalesLineItem, we haveprivate
    ProductSpecification productSpec

From Fig 20.3, p. 305
9
Mapping Designs to Code
  • Methods are generally defined as publicpublic
    Currency getSubtotal()
  • Attributes may be combined if the language
    allows e.g. Date and Time are often the same
    variable
  • This is where understanding your development
    framework can greatly simplify implementation
  • Traits like Last and Length may also help

10
Methods from Interaction Diagrams
  • Given this part of a collaboration diagram

11
Methods from Interaction Diagrams
  • We know that Register is responsible for
    implementing the method enterItem, which must
  • Use the id to get the specification of that
    catalog item from the Product catalog, and
  • Make a new line item with that specification for
    a given quantity
  • Note from Fig 20.6 that Register doesnt care
    how ProductCatalog and Sale do their work

12
Methods from Interaction Diagrams
  • Hence in Java, within the definition of the
    Register class, this method becomes (see pp. 308
    and 314)public void enterItem(ItemID itemID,
    int qty) ProductSpecification spec
    catalog.getSpecification(itemID)sale.makeLineIte
    m(spec, qty)

13
Other Implementation Issues
  • Container or collection classes are implemented
    via special non-primitive data types such as
    hash tables or array lists
  • Exceptions or errors are handled via messages
    with a stereotype of ltltexceptiongtgt (see Ch. 33)

14
Order of Implementation
  • Generally, within a set of closely associated
    classes (such as a package), implementation is
    often done starting with the simplest (least
    depended upon) classes, then working from there
    to the most heavily dependant classes (see p. 311)

15
Testing
  • One optional technique, from Extreme Programming
    (XP), is to write test code for a unit of code,
    then write the code and test it
  • Then write test code for another unit, write the
    code, and test it
  • Repeat until done

16
Tools for OOAD
  • Tools for drawing UML diagrams should support the
    creative process of development
  • If the tool is too cumbersome, then developers
    will avoid it
  • Each development team needs to determine a
    balance between scribbling on white boards,
    versus documenting designs as they go

17
Tools for OOAD
  • The RUP tries to strike a clear balance between
    thoughtful design and actual implementation
  • We want developers to think about their design
    before coding, without turning the entire project
    into a Gedankenexperiment
  • Recommend 2- to 4-week iterations, with the first
    ½ to 2 days for just diagramming

18
Tools for OOAD
  • Good to avoid anyone getting too isolated during
    design and implementation
  • Either have people work in pairs,
  • Or rotate the architect through various work
    groups to help look for conflict collaboration
  • As we have noted, no tool does UML drawings per
    the exact specification, but the ideas should
    still be clear

19
Other RUP Comments
  • The RUP is use case driven best to focus on
    high risk and high value areas (like the core
    architecture) first
  • Get lots of user feedback where possible
  • Verify quality early and often
  • Share design thoughts and test resulting code
  • Manage requirements carefully they will change!

20
Construction Transition Phases
  • The Construction Phase of the RUP is to finish
    building the system, test it, and prepare for
    deployment
  • The Transition Phase is when the system is ready
    for deployment, and is put into actual day-to-day
    use

21
Other RUP Notes
  • Recall that each iteration is put into a defined
    time interval, a timebox
  • This is to help keep everyone focused, establish
    clear priorities, and keep the stakeholders clear
    on what has been accomplished
  • The RUP can also have an Analysis Model, but
    this is just a first draft of the Domain Model

22
Review
  • Weve been studying object-oriented analysis and
    design for software duh
  • Objects differ from entities in several ways
  • Objects define the methods used to access data
  • Objects include screens, reports, and scripts
    which didnt appear in a traditional ERD
  • Objects can be created and destroyed
  • Objects can use inheritance

23
Use Cases
  • We capture (mostly) functional requirements using
    use cases
  • Each use case describes some way a user (actor)
    uses the system
  • Documentation for use cases helps capture
    non-functional requirements
  • A use case diagram summarizes the main use cases
    needed for the system

24
Use Cases
  • Use cases form the basis for our Rational Unified
    Process life cycle
  • The system is analyzed, designed, and implemented
    in a series of iterations, where each iteration
    is based on a use case

25
UML
  • We have been using the Unified Modeling Language
    to express these diagrams, a common symbolic
    language which anyone versed in OOAD should know
  • UML has been the de facto standard since about
    1999

26
Domain Model
  • The conceptual class diagram is our model of the
    domain of our system
  • It shows conceptual classes and how they might be
    associated with each other
  • We dont deal with the methods for each class yet

27
Interaction Diagrams
  • For a system sequence diagram, the system might
    be represented by a single class to see how
    various actors need to communicate with it
  • Then we use interaction diagrams (namely,
    sequence and collaboration diagrams) for each use
    case to understand what kind of methods may be
    needed to fulfill its purpose

28
Interaction Diagrams
  • The Interaction Diagrams show the time sequence
    of messages between classes, and indicate when
    decisions are made

29
Statechart Diagram
  • Heavily time-dependent use cases can be modeled
    using a statechart diagram
  • This shows the possible states of the system, and
    what events cause it to change state

30
Activity Diagram
  • Use cases which are heavily dependent upon
    different organizational involvement can be
    modeled with activity diagrams
  • They show what processes, decisions, or actions
    are done by each organization, and how
    responsibility for continuing the process is
    handed off to the next organization

31
Design Class Diagram
  • The design class diagram needs the conceptual
    classes turned into software classes
  • Based on the interaction diagrams, the design
    class diagram adds methods to each class to show
    what it is responsible for implementation

32
Patterns
  • We have examined several patterns, so that we can
    learn from the most reliable ways of getting
    common tasks accomplished
  • The patterns tell us how we might solve common
    problems, and can provide ways to improve the
    class diagrams
  • The scope of a pattern can be large or small

33
Application Class Diagram
  • The design class diagram becomes the application
    class diagram by adding the boundary and control
    objects, and reference attributes
  • This is the last version of the class diagram
    before implementation

34
Object Diagram
  • A snapshot of the application class diagram at
    one moment in time is the object diagram
  • This can be useful to show which specific objects
    have been created, at some point in a use case

35
Entity Relationship Diagram
  • The ERD may be extracted from the application
    class diagram, if the system will be implemented
    using a relational database

36
Packaging the System
  • Classes are grouped into packages to give a
    logically larger structure to system
  • Packages are then grouped into components, which
    will also include the off-the-shelf components of
    your system
  • Physical arrangement of components is shown with
    a deployment diagram
  • Sets of components may form subsystems

37
Lots of Pretty Pictures
  • So the net result of this is a growing collection
    of diagrams and documentation which capture
  • The system needs
  • How the system will be structured and communicate
    with itself and the outside world (including its
    users)

38
The Customer Had Better Win
  • But no matter how spiffily we design the system,
    we need to ensure that we are meeting the needs
    (and where possible, the wants) of the customer
    who buys the system, and the user who works with
    it
  • If we forget them, the system may be thought a
    failure, no matter what it can do!

yes, its a word I said so. ?
Write a Comment
User Comments (0)
About PowerShow.com