Presentation is loading. Please wait.

Presentation is loading. Please wait.

ICONIX P ROCESS FOR S OFTWARE D EVELOPMENT Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn 1.

Similar presentations


Presentation on theme: "ICONIX P ROCESS FOR S OFTWARE D EVELOPMENT Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn 1."— Presentation transcript:

1 ICONIX P ROCESS FOR S OFTWARE D EVELOPMENT Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn 1

2 Architecture Follows Process Good organizations know what their process is ◦ So that they can repeat their successes ICONIX is a “lite” version of Rational Unified Process (RUP) and its kin ◦ The bigger the project, the more formalism you need 2

3 Roadmap 3 GUI Prototype Use Cases Robustness Diagram Sequence Diagram Domain Model Class Diagram Code

4 How to Get From Uses Cases to Code? 4 Use Cases Code GUI Prototype ?

5 Work Backwards We need a complete set of classes, with accompanying attributes and methods ◦ So we need design-level class diagrams Before we have methods, we need to allocate behavior to classes ◦ So we need sequence diagrams for the use cases 5

6 …Work Backwards Before we do sequence diagrams, we need to know which objects are involved in which use cases ◦ Get this information from robustness diagrams ◦ Which are produced by robustness analysis ◦ Which is not part of the UML standard, but is very useful 6

7 …Work Backwards Before we can do robustness analysis, we need a domain model ◦ Need this anyway so that we can be sure we understand the customer’s view of the world So now let’s work forward 7

8 Step 1: Requirements Identify real-world domain objects and the relationships between them Prototype a GUI Identify use cases Milestone 1: requirements review 8

9 Step 2: Analysis Write use cases Perform robustness analysis ◦ Identify objects used in each use case ◦ Update domain model Milestone 2: preliminary design review 9

10 Step 3: Design Identify messages sent between objects Finish turning domain model into class diagram ◦ Add visibility, member variables, etc. ◦ Decide relationship types Milestone 3: detailed design review 10

11 Step 4: Delivery Write unit tests Write code Perform integration testing Milestone 4: deployment 11

12 Requirements Revisited Sometimes called the "discovery" phase ◦ Discover what the customer wants ◦ Discover how the system wants to be built Goal is to build a coherent vocabulary 12 GUI Prototype Use Cases Domain Model

13 Grammatical Discovery Simplest way to get started is grammatical discovery ◦ Interview customer (or read email archive) ◦ Nouns become objects, verbs become methods Don't spend too much time in this phase ◦ Even on a large project, a few days is plenty of time to evolve a problem-specific language that you can use for the rest of the work 13

14 What To Look For Duplicate terms Which objects interact directly with which Which objects generalize which Which objects "own" or "contain" which ◦ Worry about multiplicity later ◦ But make a note if a relationship has properties 14

15 Domain Modeling Errors Don't assign multiplicities early Dont' try to do use cases, domain modeling, and GUI prototyping independently Don't worry about using generics, relational database tables, etc., at this stage Don't try to impose design patterns 15

16 Analysis Revisited Bridge between analysis and design What does each thing actually do? 16 Use Cases Robustness Diagram Sequence Diagram Domain Model

17 Purpose of Robustness Analysis Sanity check on use cases Completeness check: are all alternative cases accounted for? Ongoing discovery of objects Preliminary design 17

18 Three Types of Objects Boundary objects are things that actors (e.g., users) interact with ◦ Windows, dialogs, etc. Entity objects are long-lived data ◦ Typically mapped to database tables Control objects contain the application's intelligence Yes, this is Model-View-Controller… 18

19 Drawing Robustness Diagrams 19 Boundary object Entity object Control object Allowed Not Allowed

20 Interaction Analysis Robustness analysis told us which objects talk to which Interaction analysis tells us what they say Translate use cases into sequence diagrams ◦ Translation can't be done directly if we don't know what objects we have 20

21 Sequence Diagram Format Each sequence diagram should contain: ◦ The text of the use case ◦ Objects (use the robustness diagram icons) ◦ Messages (arrows between lifelines) ◦ Method names (labels on arrows) Advanced tools can produce these semi- automatically 21

22 How To Tell If It's Right Does it meet the first lecture's criteria? ◦ Single Responsibility Principle ◦ Liskov Substitution Principle ◦ Law of Demeter This is the time to use collaboration diagrams and state diagrams ◦ If you're going to use them at all… 22

23 Classes and Code After all this, the final design and coding are straightforward 23 Sequence Diagram Domain Model Class Diagram Code

24 Thank you! … 24


Download ppt "ICONIX P ROCESS FOR S OFTWARE D EVELOPMENT Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn 1."

Similar presentations


Ads by Google