1

Use Case Driven ObjectModeling with UML - Example

Ole-Christoffer GranmoOle.Granmo@hia.no

http://osys.grm.hia.no/home/oleg

OverviewIn these slides the four phases of the ICONIX approach, namely

requirement analysis,analysis and preliminary design,design, andimplementation,

are summarized.Also, the three first phases are exemplifiedthrough the development of a Medical Journal Register

2

Requirement AnalysisIdentify your real-world domainconcepts and the generalization and aggregation relationships among thoseobjectsIf it’s feasible, do some rapid prototyping of the proposed system

Domain ModelingTo discover candidate classes, pass throughrelevant material and highlight nouns and noun phraseAlong the way, build a list of candidateassociations (static relationships betweenclasses) by identifying verbs and verb phrasesRemove actions from the candidateassociation list (actions involving two classesare best represented as operations and messages)

3

Domain Modeling IIA generalization is a relationship in whichone class is a refinement of another classA generalization can thus be seen as a kind-of relationship, where one class is a kind ofanother class

E.g. Doctor is a kind-of Medical Personell and Secretary is a kind-of Medical Personell

The former class is called the subclass whilethe latter class is called the superclassDiscovering generalization relationships is important as such relationships allow modelreuse

Domain Modeling IIIIn the following slides, therequirements of the Medical Journal Register are summarizedAlong the way, grammatical inspectionis performed

Nouns and noun phrases are highlighted in redVerb and verb phrases are highlighted in blue

4

Example Problem IIn the example you are to develop a system for managing patient journalsA journal consists of records; a doctor or some other medical personnel can insert a record. A record can for example be a description of a consultation or results from a medical test carried out by a secretaryOnly a doctor can create a journal. All medical personnel have access to the same system even if they work at different offices

Example Problem IIThe system should cater for the following:

A doctor works at one or more offices. The same goes for all medical personnelAn office can have many doctorsA patient has exactly one journalFor each office the office name should be registeredFor medical personnel: name and where he/she works (office) should be registeredName should be registered for each patient

5

Example Problem IIIThe system should cater for the following:

For each journal: patient name should be registered. Each record describes a consultation or a test resultIt should also be possible to get the following information from the system:

The journal of a patientHow many doctors the patient has been toHow many offices a patient has been toHow many records a doctor (or other medical personnel) has inserted (totally)How many records have been inserted from a particular office

Candidate Classes DiscoveredThe following candidate classes have beendiscovered based on noun and noun phrases:

JournalPatient (name)RecordDoctorMedical PersonellDescriptionConsultationTest resultOffice (name)Secretary

6

Candidate AssociationsDiscovered

The following candidate associations have been discovered based on verb and verb phrases:

Journal consists of RecordsDoctor creates JournalDoctor works at OfficeMedical Personell works at OfficeMedical Personell inserts RecordRecord describes ConsultationRecord describes Test ResultRecord inserted at Office

Candidate AssociationsDiscovered

The following candidate associationscan be added based on further problem domain analysis:

Journal concerns PatientRecord is a part-of Journal (aggregationrelationship)

7

Draw an Analysis-Level ClassDiagram

Finally, the discovered classes, associationsand generalizations is put on one diagriamThis analysis-level class diagram serves as the foundation for expanded class diagrams at the design and implementation levels later in the processThe analysis-level class diagram also serves as a glossary of terms that writers of usecases can use in the early stages of thateffort

8

Analysis and PreliminaryDesign II

Identify your use cases, using use case diagramsOrganize the use cases into groups. Capture this information in a packagediagramAllocate functional requirements to theuse cases and domain objects at thisstage

9

Analysis and PreliminaryDesign III

Write descriptions of the use cases –basic courses of actions that representthe ”mainstream” and alternative courses

10

Robustness AnalysisPerform robustness analysis. For eachuse case:

Identify a first cut of objects thataccomplish the stated scenario. Use UML Objectory stereotypes (Boundary Objects, Control Objects, and Entity Objects)

11

12

Preliminary Class DiagramUpdate your domain-model classdiagram with new objects and attributes as you discover themFinish updating the class diagram so that it reflects the completion of theanalysis phase of the project

13

Design IAllocate behavior. For each use case:

Identify the messages that need to be passed between objects, the objects, and the associated methods to be invokedDraw a sequence diagram with use casetext running down the left side and design information on the right

14

15

Design IIContinue to update the class diagram with attributes and operations as youfind them

16

Design IIIIf you wish, use a collaboration diagram to show the key transactions betweenobjectsIf you wish, use a state diagram to show the real-time behavior

17

ImplementationAs needed, produce diagrams, such as deployment and component diagrams, thatwill help you with the implementation phaseWrite/generate codePerform unit and integration testingPerform system and user-acceptance testing, sing the use cases as black-box test cases for the latter