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. ?