CSC 395 – Software Engineering Lecture 14: Object-Oriented Analysis –or– Ripping the Band-Aid Off Quickly

Remember Last Night… Iterative process from Wednesday Starts with simple use class… … generates scenarios showing how it can play out Using understanding gained from the scenarios… …finds the modules & how they interact… …and CRC cards verify actions assigned correctly Reviews use cases to determine order of events… …and checks that

Is It Soup Yet? Workflow ends with full set of specifications But we only have set of high-level modules! Remainder of workflow creates specifications Start with use case & a usable description… …show high-level modules needed for use case Write how single instance of use case plays out… …show how objects correctly perform it… …and make it possible for the client to read

Use Case Realization Once entity classes found (for now) Analysis workflow realizes (refines) use cases Realization of specific scenario of use case uses sequence or collaborations diagrams These are diagrams showing class interactions Start examining use case’s scenario and UML class models Shows how scenario plays out in analysis

Start With a Use Case Well constructed use cases are worthless without a description

Consider Class Diagram Found during 1 st phase of workflow Shows relationship between classes Classes types Associations Where workers involved By itself, basically worthless

Description Is Not a Scenario!

Let’s Get Real… We use objects not classes Object types in UML written : Class Currently show classes & their relationships Actual objects hinted at via multiplicities But otherwise object do not exist… …nor do temporal relationships Making this useless for real implementations We need something more

Collaboration Diagram Draws a scenario Show ordering Works with objects This could actually be converted to code But is specific to 1 scenario

Remember the Goal… Workflow ends with specification document Specification document is approved by client No client approves a document they do not understand Therefore must also provide flow of events (written description of collaboration diagram)

Flow of Events Will be handed off for client to approve So the speling and grammar better be good Part of the specification document Main deliverable resulting from this workflow Numbers refer to entries in collaboration diagram

Sequence Diagram Alternate method of showing object collaborations Contain identical information Time advances as we move down page This is easier to read But less focused on classes

Second Stage of Analysis Get project ready for design (& no client) Start with use case & a usable description… …show high-level modules needed for use case Write how single instance of use case plays out… …show how objects correctly perform it… …and make it possible for the client to read

In The Next Lecture Now have an analysis and potential classes But only vague concept of fields & methods Use-cases still semi-independent Not a single product or close to implementation Now transitioning into design workflow Look for ways to make modules reusable Check that ideas will be maintainable Make implementation easy for the code monkeys