INFO 620Lecture #101 Information Systems Analysis and Design Implementation Concerns, Review INFO 620 Glenn Booker

INFO 620Lecture #102 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 620Lecture #103 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 620Lecture #104 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 620Lecture #105 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 620Lecture #106 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 620Lecture #107 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 620Lecture #108 Mapping Designs to Code Reference attributes are also often private In SalesLineItem, we have: private ProductSpecification productSpec; > From Fig 20.3, p. 305

INFO 620Lecture #109 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 620Lecture #1010 Methods from Interaction Diagrams Given this part of a collaboration diagram:

INFO 620Lecture #1011 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 620Lecture #1012 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 620Lecture #1013 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 620Lecture #1014 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 620Lecture #1015 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 620Lecture #1016 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 620Lecture #1017 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 620Lecture #1018 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 620Lecture #1019 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 620Lecture #1020 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 620Lecture #1021 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 620Lecture #1022 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 620Lecture #1023 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 620Lecture #1024 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 620Lecture #1025 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 620Lecture #1026 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 620Lecture #1027 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 620Lecture #1028 Interaction Diagrams The Interaction Diagrams show the time sequence of messages between classes, and indicate when decisions are made

INFO 620Lecture #1029 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 620Lecture #1030 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 620Lecture #1031 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 620Lecture #1032 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 620Lecture #1033 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 620Lecture #1034 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 620Lecture #1035 Entity Relationship Diagram The ERD may be extracted from the application class diagram, if the system will be implemented using a relational database

INFO 620Lecture #1036 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 620Lecture #1037 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 620Lecture #1038 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.