+ All Categories
Home > Documents > Analysis (notes 2) - staff.city.ac.uk

Analysis (notes 2) - staff.city.ac.uk

Date post: 18-Feb-2022
Category:
Upload: others
View: 1 times
Download: 0 times
Share this document with a friend
26
Software Engineering Page 1 21/10/2009 E L Bodanese Dr. Eliane L. Bodanese Analysis (notes 2) 2 Agenda Analysis Workflow Example Analysis for the Library System Activity 1. Architectural Analysis Activity 2. Analyse a Use Case Activity 3. Analyse a Class Activity 4. Analyse a Package
Transcript

Software EngineeringSoftware Engineering

Page 121/10/2009E L Bodanese

Dr. Eliane L. Bodanese

Analysis (notes 2)

2

Agenda

Analysis Workflow ExampleAnalysis for the Library System

Activity 1. Architectural AnalysisActivity 2. Analyse a Use CaseActivity 3. Analyse a ClassActivity 4. Analyse a Package

Software EngineeringSoftware Engineering

Page 221/10/2009E L Bodanese

3

1. Architectural Analysis for LSFrom the results of the capturing requirements workflow for the LS

Use case modelBusiness modelArchitecture descriptionSupplementary requirements

We need to perform the first analysis activity:1.1 Identifying analysis packages

The advise from the previous slides in Analysis we can take:A first approach is to allocate the main portion of use cases to a specific package and then realise the correspondent functionality within that package

The use cases support a specific business processThe use case support a specific actorThe use case are related by generalisations or extensions

4

1.1 Identify Analysis Packages

Reserve book

Borrow bookcopyBook Borrower

Return bookcopy

Extend loanbook copy

Current Use Case model for LS

<<include>>

<<include>>

<<include>>

<<include>>

IdentifyLM

<<include>>

<<include>>

<<include>>

<<include>>

Identifyitem

Print returndate

<<include>><<extends>>

if using library machine

printer

Checkreservation

<<include>>

<<include>>

Software EngineeringSoftware Engineering

Page 321/10/2009E L Bodanese

5

1.1 Identify Analysis PackagesReserve journal

Borrow journalcopyJournal Borrower

Return journalcopy

Extend loan of Journal copy

Current Use Case model for LS

IdentifyLM

<<include>>

<<include>>

<<include>>

<<include>>

Print returndate

<<include>><<extends>>

if using library machine

printer

<<include>>

<<include>>

<<include>>

<<include>>

Identifyitem

Checkreservation

<<include>>

<<include>>

6

UpdateCatalogue

Librarian

Apply Fine

printer

Browser

Browse

IdentifyLM

<<include>>

<<include>>

Current Use Case model for LS

1.1 Identify Analysis Packages

Software EngineeringSoftware Engineering

Page 421/10/2009E L Bodanese

7

Identifyitem <<extends>>

if using barcode

scanner

Identifybarcode

IdentifyLM

<<extends>>

if using barcode

1.1 Identify Analysis Packages

Current Use Case model for LS

8

1.1 Identify Analysis PackagesBookBorrower’s Mgmt

Book Borrower

JournalBorrower’s Mgmt

Journal Borrower

Librarian’s Mgmt

Librarian

Browser’s Mgmt

Browser

Software EngineeringSoftware Engineering

Page 521/10/2009E L Bodanese

9

1.1 Identify Analysis Packages

Printer

Scanner’s Mgmt

Scanner

Printer’s Mgmt 1.1.1 Find commonality among analysis classes (later)1.1.2 Identifying Services Packages (later)1.1.3 Define Analysis packages dependencies (later)We need to know the analysis classes to do these activities

10

1.1 Identify Analysis Packages

Item identification’s Mgmt

LM identification’s MgmtReservations’ Mgmt

Finding commonalitiesServices Packages

candidates

Software EngineeringSoftware Engineering

Page 621/10/2009E L Bodanese

11

1.2 Identify Obvious Entity classesFrom the use case model we can extract the following obvious entity classes:

bookbook_copyjournal (when you read the system description we can decide that there is only one copy of each journal issue or that we will also consider a copy of Journal)journal_copy (to keep generality)Library member info (maybe later disassociated in student and staff (academic/non-academic))itemCatalogueFine infoBook reservation listJournal reservation list

12

1.3 Identify Common Special Requirements

They are commonly restrictions or constrainsPersistence, distribution and concurrency, security features, fault tolerance, transaction managementExample for the Library System:

All obvious entities are persistent objectsThe use cases run concurrentlyThere are several instances of the main user interface running concurrently and they are distributed in the Library networkAll persistent data is mirroredThe system is mirroredCatalogue update is free of interferenceLibrary members are identified by their respective barcode numbers and passwordsLibrary items are identified by their respective barcode numbers

Software EngineeringSoftware Engineering

Page 721/10/2009E L Bodanese

13

2. Analyse a Use caseThe Use-Case engineer needs to

Identify Analysis classesDescribe Analysis object interactionsCapture special requirements

2.1 Identifying Analysis classesBy studying the use case description and any existing business or domain model

Identify entity classesIdentify one boundary class for each human actor, external system actor Identify one control class to control and coordinate the use case realisationCollect all the participating classes of the use case realisation in a class diagram

14

2. Analyse a Use caseIt is difficult to decide from each use case to startIf we take for example the use case Borrow book copy :

From its original flow of events, we would findPre-condition:

The Book Borrower (BB) presents a bookFlow of Events:

Basic PathThe BB invokes the use case by applying for a book loan. The system checks if the potential borrower is a library member (LM). If BB is a LM it continues, Otherwise, refuses the request.

From this segment of the flow we could identify:

BB_ui LM BB_control

Software EngineeringSoftware Engineering

Page 821/10/2009E L Bodanese

15

2.1 Identifying Analysis Classes2. The system checks if the LM is a member of staff (MS) or a student (S). If the LM is a MS, the system checks if the BB has already borrowed 12 items. If yes, the system refuses the loan. If the BB is a S, the system checks if the BB has already borrowed 6 items. If yes, the system refuses the loan.

From this segment of the flow we can identify:

staff student items_on_loan

16

2.1 Identifying Analysis Classes3.The system verifies whether there is a reservation for the book. The system searches the list of outstanding reservations for that book. If it finds any, it compares the number of reservation, n, with the number of copies of the book known to be on the reserved book shelf, m. If n>m then the system returns that this copy is reserved. If the book is reserved, the system refuses to lend itFrom this segment of the flow we can identify:

4.Otherwise, it records that the BB now has this copy of the book on loan and prompts for the book to be stamped with the return date.From this segment of the flow we can identify:

book_reservation_list reserved_book_shelf book_copy book

printer_interface

Software EngineeringSoftware Engineering

Page 921/10/2009E L Bodanese

17

2.1 Identifying Analysis Classes

Alternative Paths:The BB can in any step give up borrowing the book and cancel the application

The cancel button is inside the BB_ui

Post condition:The book has been borrowed and the system has updated the status of the book and the return date, or the loan was refused.

Done by the BB_control over the respective entity objects

18

2.1 Identifying Analysis ClassesClass Diagram for Borrow book copy

BBBB_ui

LM

BB_control

staff student

items_on_loan

book_reservation_list

reserved_book_shelf

book_copy bookprinter_interface

Software EngineeringSoftware Engineering

Page 1021/10/2009E L Bodanese

19

2.1 Identifying Analysis ClassesBut we know that the Borrow book copy use case includes other use cases:Step 1 is performed by

Identify LM use casePart of step 2 is performed by

Identify Item use casePart of step 3 is performed by

Check reservation use casePart of step 4 is performed by

Print the return date use caseThen it is difficult to find the analysis classes and interactions, because we do not know if we are repeating what the included use cases have or interactTherefore, it is better to start by the most common included use cases

20

2.1 Identifying Analysis ClassesFor the use case: Identify Library Member (LM)

Pre-condition: Another use case wants to check the LM’s identification

Flow of Events: Basic Path

The system requests the id to the LM and his/her password.The system checks if the user is a library member (LM) and if his/her password is correct. If he/she is a valid LM , the system sends an affirmative answer to the requester use case. Otherwise, the system sends a negative answer.

Alternative path:The LM can use his/her barcode to enter his/her identification (left as implicit actor for simplicity)

Post condition:The Library Member is successfully identified or a negative answer is sent.

From this use case we can identify:

ILM_ui LM ILM_control

Software EngineeringSoftware Engineering

Page 1121/10/2009E L Bodanese

21

2.1 Identifying Analysis ClassesClass Diagram for Identify LM

LMILM_ui

LM

ILM_control

staff student

22

2.2 Describing Analysis Objects Interactions

A collaboration diagram is created by starting from the beginning of the flow of the use case, and then going through one step at a time, deciding which objects need to interact to realize that stepEach identified analysis class (activity 2.1) should have at least one object participating in the collaboration diagram (if not, the analysis class is superfluous and should be erased)

LM

ILM_ui

LM

ILM_control3:enter LM Id

2:id LM request

5:get LM id

4: check id

staff student

6:LM id

7: reply check (OK or Refuse)

0:check LM’s id1:id LM request

requester

Software EngineeringSoftware Engineering

Page 1221/10/2009E L Bodanese

23

2.3 Special Requirements

Special Requirements for Identify LM use caseThe password needs to be encryptedThe password needs to be 7 characters or longerThe check of the LM’s id cannot take longer than 1 second

24

2.1 Identifying Analysis Classes

For the use case: Identify ItemPre-condition:

Another use case wants to check the item’s identityFlow of Events: Basic Path

The system requests to the LM to enter the book identification via scanner or typing the number.The system checks if the identification of the item is valid.If it is valid, the system gets the correspondent item information and sends

to the requester use case. Otherwise, the system responds with a negative answer.

Post condition:The item is successfully identified or its invalid.

From this use case we can identify:

II_ui item II_control

Software EngineeringSoftware Engineering

Page 1321/10/2009E L Bodanese

25

2.1 Identifying Analysis ClassesClass Diagram for Identify Item

LMII_ui

item

II_control

book_copy journal_copybook journal

26

2.2 Describing Analysis Objects Interactions

LM

II_ui

item

II_control

3:receive item id

5:get item info

4: check id

book_copy journal_copy

6:send item info

7: reply check (item info or Refuse)

Collaboration Diagram for Identify Item

book journal

0:check item’s id(type)requester

1:item id request 2:item id request

Software EngineeringSoftware Engineering

Page 1421/10/2009E L Bodanese

27

2.3 Special RequirementsSpecial Requirements for Identify Item use case:

For some use case requesters the LM can enter the number of the book without using the scanner. This information needs to come inside the triggering request.The scanner is treated as an implicit actor.The item identification check cannot take longer than 1 second

28

2.1 Identifying Analysis Classes

For the use case: Identify BarcodePre-condition:

A scanner (barcode reader) has been usedFlow of Events: Basic Path

The system gets the information from the scanner.If the information is valid, continue. Otherwise send error message.

Post condition:The item is successfully identified or its invalid.

From this use case we can identify:

IB_interface

Software EngineeringSoftware Engineering

Page 1521/10/2009E L Bodanese

29

2.1 Identifying Analysis ClassesClass Diagram for Identify Barcode

ScannerIB_interface

Collaboration Diagram for Identify Barcode

ScannerIB_interface

1:check barcode info

30

2.1 Identifying Analysis ClassesFor the use case: Check Reservation

Pre-condition: Another use case wants to check item reservation

Flow of Events: Basic Path• The system verifies whether there is a reservation for the item. The system

searches the list of outstanding reservations for that item. If it finds any, it compares the number of reservation, n, with the number of copies of the item known to be on the reserved shelf, m. If n>m then the system returns that this copy is reserved. Otherwise, the system returns the item is not reserved.

Post condition:The item is reserved or not.

From this use case we can identify:

item CR_controlitem_reservation_list reserved_shelf

Software EngineeringSoftware Engineering

Page 1621/10/2009E L Bodanese

31

2.1 Identifying Analysis ClassesClass Diagram for Check Reservation

item

CR_control

book_copy journal_copybook journal

item_reservation_list

reserved_shelf

32

2.2 Describing Analysis Objects Interactions

Collaboration Diagram Check Reservation

item

CR_control

book_copy journal_copybook journal

item_reservation_list

reserved_shelf

0:check item reservation

1:get outstanding reservation

2:check res. list against reservation shelf

3:check reservation responserequester

Software EngineeringSoftware Engineering

Page 1721/10/2009E L Bodanese

33

2.1 Identifying Analysis ClassesFor the use case: Print return date

Pre-condition: Another use case wants to print return date

Flow of Events: Basic Path

The system delivers the information to the printer.If the printer is okay and ready, continue. Otherwise send errormessage ( to simplify, we are not treating this error).

Post condition:The return date is successfully printed or an error message was issued.

From this use case we can identify:

PRD_interface

34

2.1 Identifying Analysis ClassesClass Diagram for Print return date

PrinterPRD_interface

Collaboration Diagram for Print return date

PrinterPRD_interface

1:send date information 0:print return date (information)

requester

Software EngineeringSoftware Engineering

Page 1821/10/2009E L Bodanese

35

2.1 Identifying Analysis ClassesNow we can perform the realisation of the use case: Borrow book copy

Pre-condition: The Book Borrower (BB) presents a book

Flow of Events: Basic Path

1. The BB invokes the use case by applying for a book loan.2. The system uses the identify LM use case. If BB is a LM it continues, otherwise,

refuses the request.3. If the LM is a MS, the system checks if the BB has already borrowed 12 items. If

yes, the system refuses the loan. If the BB is a S, the system checks if the BB has already borrowed 6 items. If yes, the system refuses the loan.

4. The system identifies the book using the identify item use case. If the item has a valid book identification, it continues, otherwise an error message is issued (to simplify, it refuses the loan).

5. The system verifies whether there is a reservation for the book, using the check reservation use case. If the book is reserved, the system refuses the request. Otherwise, it continues.

6. It records that the BB now has this copy of the book on loan and uses the print return date use case to issue the return date of the copy of the book.

36

2.1 Identifying Analysis ClassesFrom the basic path segment of the flow we can identify:

Alternative Paths:The BB can in any step give up borrowing the book and cancel the application

The cancel button is inside the BB_uiPost condition:

The book has been borrowed and the system has updated the status of the book and the return date, or the loan was refused.Done by the BB_control over the respective entity object

BB_ui items_on _loan BB_control LMbook_copy

Software EngineeringSoftware Engineering

Page 1921/10/2009E L Bodanese

37

2.1 Identifying Analysis ClassesClass Diagram for Borrow book copy

BBBB_ui

LM

BB_control

staff student

items_on_loan

book_copy

item

38

BBBB_ui

LM

BB_control

1:select borrow book2:borrow book

5:check items in loan

3:check LM,s id

6/7/9/11: show refusal

4:receive LM check response

ILM_control

5/6/8/10: refuse loan

staff student

items_on_loan

6:check item’s id (type)

II_control

7:receive item check response (item info or no)

8:check reservation

CR_control

9:receive reservation check response

PRD_interface

11:print return date (information)

Collaboration Diagram for Borrow book copy book_copy book

10:update

item

Software EngineeringSoftware Engineering

Page 2021/10/2009E L Bodanese

39

Activity 3. Analyse a ClassExercise

Perform the use case realisation for the other use cases of the Library System

Let’s start activity 3 of the Analysis workflowIdentify and maintain the responsibilities of an analysis class,based on the role it acts in the use case realisationsIdentify and maintain the attributes and relationships of the analysis classCapture special requirements

3.1 Identifying ResponsibilitiesExtract all use-case realisations that the class participatesExtract the responsibilities from each role the class takes

40

Activity 3. Analyse a Class3.2 Identifying Attributes

An attribute specifies a property of an analysis classA noun is used to name the attributeAttribute types are conceptual at the analysis level. Ex. Amount and not integerTry to reuse attributesA single attribute instance cannot be shared by several analysis objects

If this is the case, the attribute needs to be defined in its own classAttributes of entity classes are fairly obviousBoundary attributes are normally information items manipulated by actorsBoundary attributes interacting with external systems are normally properties of communication interfaceControl attributes are rare

Software EngineeringSoftware Engineering

Page 2121/10/2009E L Bodanese

41

Activity 3. Analyse a Class3.3 Identifying Associations and aggregations

Objects interact via links in collaboration diagramsOften these links are instances of associations between the corresponding classes of objectsThe component engineer also defines association multiplicities

3.4 Identifying generalisations3.5 Capturing Special RequirementsPerforming the five sub activities with the classes:

ILM_controlILM_uiLMstaffstudent

42

Analyse a Class: ILM_controlThis control class is only used in the Identify LM use caseResponsibilities

Receives the request for identification of a LMRequests the identification of the LMGets the identification of the LMCheck if the id number corresponds to a valid LM and its password is correct (implicit interaction with secure database)Issue the affirmative or negative valid identification

AttributesValid id

Associations and aggregationsNone

generalisationsNone

Special RequirementsThe id and password check needs to be secure

ILM_control

Software EngineeringSoftware Engineering

Page 2221/10/2009E L Bodanese

43

Analyse a Class: ILM_uiThis boundary class is only used in the Identify LM use caseResponsibilities

Receives the request for identification of a LM from controlRequests the identification to the LM via user interfaceSenses which type of input the LM is giving (barcode, typing number)Gets the identification of the LM and passwordSends information to controlGets final answer from control (refusal or acceptance)

AttributesLibrary numberPasswordCancelNext windowsubmit

Associations and aggregationsNone

generalisationsNone

Special RequirementsThe password is case sensitiveDo not show the password charactersPassword encryption

ILM_ui

44

Analyse a Class: LMThis entity class is used in several use cases, lets analyse the ones we have already realised (Identify LM use case and Borrow a book copy use case)Responsibilities

Keep information about the LMAttributes

LM nameLM addressLM type: student/staffLM user numberLM encrypted passwordDepartment

Associations and aggregationsNone

generalisationsstudent class , staff class

Special Requirementsnone

staff

LM

student

Software EngineeringSoftware Engineering

Page 2321/10/2009E L Bodanese

45

Analyse a Class: staffThis entity class is used in several use cases, lets analyse the ones we have already realised (Identify LM use case and Borrow a book copy use case)Responsibilities

Keep information about the staff memberAttributes

staff payroll numberPositionType of items allow to borrowNumber of items allow to borrow

Associations and aggregationsitems_on_loan class

generalisationsLM class

Special Requirementsnone

staff

LM

items_on_loan

46

Analyse a Class: studentThis entity class is used in several use cases, lets analyse the ones we have already realised (Identify LM use case and Borrow a book copy use case)Responsibilities

Keep information about studentAttributes

student registration numbercourseType (full time, part time)Type of items allow to borrowNumber of items allow to borrow

Associations and aggregationsItems_on_loan class

generalisationsLM class

Special RequirementsNone

ExercisePerform the class analysis for the other classes of the Library System

student

LM

items_on_loan

Software EngineeringSoftware Engineering

Page 2421/10/2009E L Bodanese

47

Activity 4. Analyse a PackagePurpose of analysing a package

Ensure the package is independent of other packages as much as possibleEnsure the package fulfils its purposesDescribe dependencies so the effect of future changes can be estimated

Before doing this, let’s come back to activity 11.1.1 Find commonality among analysis classes1.1.2 Identifying Services Packages1.1.3 Define Analysis packages dependencies

48

BookBorrower’s Mgmt

Printer’s MgmtLM’s MgmtItem’s Mgmt

RB RBC BBC

ELBC

CR

II

ILM PRD

Scanner’s Mgmt

IB

Service package

Service package

Software EngineeringSoftware Engineering

Page 2521/10/2009E L Bodanese

49

Activity 4. Analyse a PackageExercise

Perform the activities 1.1.1 to 1.1.3 for the other packages of the Library System and after analyse each package

Let’s now analyse some of the packages: activity 4For LM’s Mgmt package

LM’s Mgmt

ILMstudent

LM

items_on_loan

staff

50

Activity 4. Analyse a PackageFor Item’s Mgmt package

Item’s Mgmt

item

book_copy journal_copybook journal

item_reservation_list

1..* 1..*

II

Software EngineeringSoftware Engineering

Page 2621/10/2009E L Bodanese

51

ReferencesJacobson I., Booch G., Rumbaugh J., “The Unified Software Development Process”, Chapter 8, Addison-Wesley, 1999.Stevens P., Pooley R. “Using UML – Software Engineering with Objects and Components”. Addison-Wesley, 2000.Fowler M., Scott K., “UML Distilled – A Brief Guide to the Standard Object Modelling Language”, Addison-Wesley, 2000.


Recommended