Software Development Method by Jan Pettersen Nytun, page 1

1

• The Iconix Development Process

2
Significant Features

• Iterative and Incremental.
• Traceability you always refer back to the
  requirements. (Objects are there to satisfy use
  cases.)
• A minimalist approach - a minimal number of
  steps and use of diagram types.

3
(No Transcript)
4
Dynamic



Use Case Model
Robustness Diagram (Class Diagram)
Static
Design Class Diagrams
Domain Model Class Diagrams
5
Requirements Analysis

• Domain Modeling
• Identify your real-world domain objects and the
  generalization and aggregation relationships
  among those objects.
• GUI design / Prototyping
• If its feasible, do some rapid prototyping of
  the proposed system. (Mine your legacy software).
  the best way to identify chunks of use cases in
  connection with a prototype is to write a rough
  user manual, as if the prototype were an actual
  fully working system.
• Use Case Modeling
• Identify your use cases.
• Organize the use cases into packages.
• Allocate functional requirements to the use cases
  and domain objects at this stage.

Cancel
Ok
6
Analysis And Preliminary Design

• Write Use Case Text
• Write a description of the normal flow (also
  called main flow, the sunny day scenario) and
  the alternate flows (extensions)
• Robustness Analysis. For Each Use Case
• Identify a first cut of objects that accomplish
  the selected scenario.
• Update your domain model and your design class
  diagrams with new classes and attributes as you
  discover them.

--- 1 --- EndUser chooses Tourism/
Environment --- 2 --- EndUser chooses fishing ---
3 ---
7
Robustness Analysis Bridging The Gap Between
Analysis And Design
Analysis (What)
Design (How)
Gap
8
Design

• Interaction Modeling (Allocate behavior).For
  Each Use Case
• Identify the messages that need to be passed
  between objects, the objects, and the associated
  methods to be involved.Draw a sequence (or
  collaboration) diagram with use case text running
  down the left side.Continue to update the design
  class diagram with attributes and operations as
  you find them.

9
Sequence Diagrams

• Robustness analysis is preliminary design
• this is much about object discovery.
• Some detailed design can be done with sequence
  diagrams
• this is much about allocating behavior
• allocating behavior among the boundary, entity,
  and control objects

10
Building a Sequence Diagram 2
Main flow xxxxxxxxxxxx Extensions xxxx xxxx
Use CaseModel
Use CaseTekst
1. Copy the use case text to the left margin
of the sequence diagram.
RobustnessDiagram
2. Add the entity objects. 3. Add the boundary
objects.4. Work through the controllers, one
at a time, and figure out how to allocate the
behavior among the collaboration objects.
SequenceDiagram
11
Dynamic



Use Case Model
Robustness Diagram (Class Diagram)
Static
Design Class Diagrams
Domain Model Class Diagrams
12
The use case model is the heart of the
approach

• Robustness analysis
• What satisfy each use case?
• Propose a set of collaborating objects that can
  solve each use case.
• Interaction modeling
• Refine the results of robustness analysis.
• Show how messages flow between the collaborating
  objects that solves each use case.

13
Robustness Diagram Symbols(Class Stereotypes)

• Control Class Manage interactions. Its behavior
  is specific to a use case, which it usually does
  not outlive.

• Boundary Class Mediate between the system and
  outside actors (e.g. sensor).

• Entity Class Passive objects, they do not
  initiate interactions. May participate in
  several use cases.

14
Alternative Representations of a Boundary Class
IconRepresentation
Labelrepresentation
Decoratedrepresentation
15
Robustness Diagram Rules
Allowed
Not Allowed
16
Use Case Robustness

• 1 youre not finished with a use case until
  the text and the robustness diagram match.

17

• Oppgave Onkel Politi
• I denne oppgaven skal du starte utviklingen av et
  elektronisk system som politiet skal bruke
• til å håndtere opplysninger i forbindelse med
  etterforskning av anmeldte saker.
• For anmeldte saker skal det være mulig å
  registrere og senere editere på
• Opplysninger om involverte personer, dvs.
  anmeldere, anmeldte, ofre (personer som
  politiet antar er ofre), mistenkte (mulige
  gjerningsmenn), siktede personer (antatte
  gjerningsmenn), vitner, politietterforskere.
• Beskrivelse av bevismateriale.
• Beskrivelse av antatt åsted.
• Vitneforklaringer og avhør.
• Det følgende skal være mulig
• Gitt en person, finne alle anmeldelser hvor
  vedkommende er angitt som gjerningsmann eller
  mistenkt.
• Gitt en person, finne alle anmeldelser
  vedkommende har gjort.
• Gitt en anmeldelse, finne alle opplysninger
  knyttet til denne anmeldelsen.
• I denne oppgaven skal du fokusere på en prototyp
  som skal ha egenskapene som er angitt
• over, prototypen har følgende begrensninger
  (forenklinger)
• En bruker
• Ikke distribuert
• Ikke permanent lagring
• Hvis en skulle laget et virkelig system så ville
  en typisk jobbe sammen med domene eksperter
• (for eksempel politietterforskere) for å få en
  forståelse av hvordan disse jobber i denne

18

• Lag en konseptuel modell, domene modell,
  som viser konseptene fra det beskrevne
  problemområde. Bruk stereotypen ltltconceptgtgt for
  klassene. Dette skal være en enkel og
  oversiktelig modell. Du skal ikke bruke
  generalisering du skal heller ikke angi
  attributter med mindre dette gjør diagrammet
  lettere å forstå operasjoner skal ikke angis
  kun klasser og assosiasjoner tar du med!
• Du må nødvendigvis gjøre en del avgrensninger
  i forhold til virkeligheten, en trenger for
  eksempel ikke å ta med domsavsigelser,
  arrestasjoner, forskjellige stillingstyper
  Ipolitiet og lignende ting!

19
Domain Model
20

• Lag use case diagram (er) som
  visualiserer bruken av systemet (gjør om
  nødvendig dine egne forutsetninger). Angi også
  use case tekst for hver enkelt use case (bruk
  nummerering osv. slik som gjennomgått i kurset).

21
Noen Use Cases
22
Use Case Forhør av mistenkt Målsetting Forhøre
mistenkt lagre forklaring i datasystemet
arkivere signert forklaring
(signert av forhører og mistenkt) MAIN SUCCESS
SCENARIO 1. Forhører registrerer og verifiserer
personalia til mistenkte. 2. Forhører noterer
mistenktes forklaring. 3. Forhører skriver ut
avgitt forklaring. 4. Mistenkte og forhører
signerer forklaringen. 5. Forhører registrerer
forklaringen i datasystemet. 6. Forhører
arkiverer signert forklaring. EXTENSIONS 1.
Personalia ikke verifisert a. Forhører
informerer mistenkte om at vedkommende vil bli
holdt i varetekt inntil personalia er verifisert
b. Forhører noterer mistenktes forklaring.
c. Forhører signerer forklaringen. d. Forhører
registrerer forklaringen i datasystemet. e.
Forhører arkiverer signert forklaring. f. end
2. Mistenkte nekter å avgi forklaring a.
Forklaringen påføres "Mistenkte nekter å
forklare seg" 4. Mistenkte nekter å signere
forklaring a. Forklaringen påføres "Mistenkte
nekter å signere" b. Forhører noterer på
forklaringen hvorfor mistenkte ikke vil signere.
23
Registrere/Editere Personalia

• Vi ser at registrere/editere på personalia inngår
  i mange use caser vi modulariserer og lager en
  egen use case som kan inkluderes!

24
Use Case Forhør av mistenkt
Målsetting Forhøre mistenkt lagre forklaring i
datasystemet arkivere
signert forklaring (signert av forhører og
mistenkt) MAIN SUCCESS SCENARIO 1.
Inkluder(Registrere/Editere Personalia)
25

• Use Case Registrere/Editere Personalia
• Målsetting Finne eventuelt opprette personalia
  til person og tillate editering på disse
• MAIN SUCCESS SCENARIO
• 1. Tjenestemannen ber personen om å oppgi
  personnummer og søker så etter personalia.
• 2. Tjenestemannen editerer om nødvendig på
  personalia.
• EXTENSIONS
• 1a. Personen kan ikke angi personnummer.
• 1. Tjenestemannen ber personen om navn.
• 2. Systemet lister alle personer med angitt
  navn.
• 3. Tjenestemannen velger rett person fra
  listen.
• 1a3 Personen er ikke registrert
• 1. Tjenestemannen registrerer personen
• 1b. Personen er ikke registrert
• 1. Tjenestemannen registrerer personen

26

• Lag en Business Type modell som dekker
  prototypen. Bruk stereotypen ltlttypegtgt for
  klassene. Hint
• - Ta utgangspunkt i den
  konseptuelle modellen
• - Denne modellen vil typisk vise
  de klassene som representerer
  persistente data (dvs. hvis systemet skulle
  være mer enn en prototyp). -
  Klasser som angir brukergrensesnitt og klasser
  som kun har med
  oppførsel skal typisk ikke være med (du skal for
  eksempel ikke angi operasjoner).
  - Bruk generalisering og de andre
  relasjonstypene. - Legg inn attributter
  som trengs for å realisere det angitte
  systemet.

27
Type modell Anmeldelse
28
Type modell Anmeldelse
29
Robustness diagram Registrere/Editere Personalia
30
(No Transcript)
31

• Design en løsning for prototypen
  beskriv denne ved hjelp av et klassediagram.
• Hint Ta utgangspunkt i business type
  modellen, legg inn operasjoner og nødvendige
  hjelpeklasser.
• Lag også et sekvensdiagram som viser en
  mulig meldingsflyt når en ny anmeldelse
  registreres.
• Ved hjelp av Java implementer løsningen du
  designet i punktet over.

32
References

• Grady Booch, James Rumbaugh and Ivar
  JacobsonThe Unified Modeling Language User
  Guide.Addison-Wesley, 1999
• James Rumbaugh, Michael Blaha, William
  Premerlani, Frederick Eddy and William Lorenzen
  Object-Oriented Modeling and Design. Prentice
  Hall, 1991
• Martin Fowler with Kendall Scott UML
  Distilled.Addison-Wesley, 1997
• Terry Quatrani Visual Modeling with Rational
  Rose and UML.Addison-Wesley, 1998
• Ari Jaaksi A Method for Your First
  Object-Oriented Project. JOOP - The Journal of
  Object-Oriented Programming, Januar 1998
• Rational software http//www.rational.com/uml/do
  cumentation.html
• 1 Doug Rosenberg and Kendall Scott Use Case
  Driven Object Modeling with UMLA Practical
  Approach Addison-Wesley
• 2 Doug Rosenberg and Kendall Scott Applying
  Use Case Driven Object Modeling with UML An
  Annotated E-Commerce Example Addison-Wesley, 2001