Information Systems Analysis and Design

Implementation Concerns, Review INFO 620 Glenn Booker Lecture #10 INFO 620 1

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 INFO 620 Lecture #10 2

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… INFO 620 Lecture #10 3

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 INFO 620 Lecture #10 4

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 INFO 620 Lecture #10 5

Defining Classes and Objects

• Classes may be declared using the format

visibility

class

classname;

where

visibility

={private,protected,public} • Objects or attributes are declared using

visibility datatype objectname;

where datatype is integer, text, etc.

• Parameters are declared using

datatype parametername;

INFO 620 Lecture #10 6

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 public: public class SalesLineItem • Most attributes are private: private int quantity INFO 620 Lecture #10 7

Mapping Designs to Code

• Reference attributes are also often private • In SalesLineItem, we have: private ProductSpecification productSpec;

SalesLineItem

-quantity : int -productSpec : ProductSpecification +getSubtotal() : Currency * Described-by

ProductSpecification

1 > -description : char -price : Currency -itemID : ItemID From Fig 20.3, p. 305 INFO 620 Lecture #10 8

Mapping Designs to Code

• Methods are generally defined as public public 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 INFO 620 Lecture #10 9

Methods from Interaction Diagrams

• Given this part of a collaboration diagram: 2: makeLineItem(spec, qty)() enterItem(id, qty)() :Register sale:Sale INFO 620 catalog:ProductCatalog Lecture #10 From Fig. 20.6, p. 307 10

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 doesn’t care how :ProductCatalog and :Sale do their work INFO 620 Lecture #10 11

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.makeLineItem(spec, qty); } INFO 620 Lecture #10 12

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 <> (see Ch. 33) INFO 620 Lecture #10 13

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) INFO 620 Lecture #10 14

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 INFO 620 Lecture #10 15

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 INFO 620 Lecture #10 16

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 INFO 620 Lecture #10 17

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 INFO 620 Lecture #10 18

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!

INFO 620 Lecture #10 19

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 INFO 620 Lecture #10 20

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 INFO 620 Lecture #10 21

Review

• We’ve 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 didn’t appear in a traditional ERD – Objects can be created and destroyed – Objects can use inheritance INFO 620 Lecture #10 22

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 INFO 620 Lecture #10 23

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 INFO 620 Lecture #10 24

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 INFO 620 Lecture #10 25

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 don’t deal with the methods for each class yet INFO 620 Lecture #10 26

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 INFO 620 Lecture #10 27

Interaction Diagrams

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

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 INFO 620 Lecture #10 29

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 INFO 620 Lecture #10 30

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 INFO 620 Lecture #10 31

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 INFO 620 Lecture #10 32

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 INFO 620 Lecture #10 33

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 INFO 620 Lecture #10 34

Entity Relationship Diagram

• The ERD may be extracted from the application class diagram, if the system will be implemented using a relational database 35 INFO 620 Lecture #10

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 INFO 620 Lecture #10 36

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) INFO 620 Lecture #10 37

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, it’s a word; I said so.

 INFO 620 Lecture #10 38