Title: Information Systems Analysis and Design Implementation Concerns, Review
1Information Systems Analysis and
DesignImplementation Concerns, Review
2Rational 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
3Rational 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
4Iterative 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
5CASE 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
6Defining 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
7Mapping 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
8Mapping Designs to Code
- Reference attributes are also often private
- In SalesLineItem, we haveprivate
ProductSpecification productSpec
From Fig 20.3, p. 305
9Mapping 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
10Methods from Interaction Diagrams
- Given this part of a collaboration diagram
11Methods 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
12Methods 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)
13Other 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)
14Order 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)
15Testing
- 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
16Tools 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
17Tools 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
18Tools 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
19Other 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!
20Construction 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
21Other 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
22Review
- 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
23Use 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
24Use 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
25UML
- 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
26Domain 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
27Interaction 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
28Interaction Diagrams
- The Interaction Diagrams show the time sequence
of messages between classes, and indicate when
decisions are made
29Statechart 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
30Activity 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
31Design 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
32Patterns
- 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
33Application 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
34Object 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
35Entity Relationship Diagram
- The ERD may be extracted from the application
class diagram, if the system will be implemented
using a relational database
36Packaging 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
37Lots 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)
38The 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. ?