18
Object-Oriented Analysis and Design

Object-Oriented Analysis and Design. Priorities in O-O Analysis and Design Understanding a system in terms of objects and associations between them. Representing

  • View
    223

  • Download
    0

Embed Size (px)

Citation preview

Object-Oriented Analysis and Design

Priorities in O-O Analysis and Design

• Understanding a system in terms of objects and associations between them.

• Representing the “real world” as faithfully as possible (reduces complexity?)

• Developing classes as reusable components.

• Facilitating iteration in requirements definition - not a “waterfall” model.

Unified Modelling Language• An attempt to produce a standard notation

for diagrams and CASE tools.

• A collection of techniques rather than a full-blown methodology.

• But is put into operation within approaches such as Rational Unified Process

“Official” representation of RUP

Source: http://www.rational.com

Principles of the RUP

1.Develop software iteratively 2.Manage requirements 3.Use component-based architectures 4.Visually model software 5.Verify software quality 6.Control changes to software

(Source: http://www.rational.com/products/whitepapers/100420.jsp#1)

Iterative Development

• Similar activities on other prototyping-led approaches

• Strong emphasis on involving users in requirements definition through the project

• Strong emphasis on “timeboxing”

• Leads to prioritisation of objectives (what is dispensible?)

A possible order of events in analysis using UML

• Use cases developed in collaboration with users (human “actors”)

• Classes derived from use cases and CRC cards

• Operations then used to inform sequence diagrams (each use case has a sequence)

Behavioural Models

• Dynamic aspects of systems behaviour

• Activities undertaken by one object as a result of messages passed by another

• Interactions between classes and users

• Examples - use case diagrams; sequence diagrams; collaboration diagrams

Static (or structural) models

• Objects and associations between them

• Indication of potential object activity (class responsibilities)

• Typically: class diagram as the structure for the system and the data dictionary

• Classes derived from use cases but then operations used to define messages passed between objects, e.g. on sequence diagrams

Class Diagram: Class Symbol

Client

companyAddresscompanyEmailcompanyFaxcompanyName

companyTelephone

Class name compartment

Attributes compartment

Operations compartment

Class Diagram: Instance Symbol

FoodCo:Client

companyAddress=Evans Farm, Norfolk

[email protected]

companyFax=01589-008636

companyName=FoodCo

companyTelephone=01589-008638

Object name compartment

Attribute values

Instances do not have operations

Class Diagram: Attributes

Attributes are:

• Part of the essential description of a class

• The common structure of what the class can ‘know’

• Each object has its own value for each attribute in its class

Class Diagram: Associations

StaffMember

staffName

staffNo

staffStartDate

Client

companyAddress

companyEmail

companyFax

companyName

companyTelephone

liaises with

staffContact

Association role Association

Association nameDirection in which name should be read

Class Diagram: Associations

Associations represent:

• The possibility of a logical relationship or connection between objects of one class and objects of another

• If two objects can be linked, their classes have an association

Class Diagram: Multiplicity

• Associations have multiplicity• Multiplicity is the range of permitted

cardinalities of an association• Represent enterprise (or business) rules• For example:

– Any bank customer may have one or more accounts

– Every account is for one, and only one, customer

Class Diagram: Multiplicity

StaffMember

staffName

staffNo

staffStartDate

Client

companyAddress

companyEmail

companyFax

companyName

companyTelephone

1 0..*

liaises with

Multiplicities

•Exactly one staff member liaises with each client

•A staff member may liaise with zero, one or more clients

Class Diagram: Operations

Operations are:

• An essential part of the description of a class

• The common behaviour shared by all objects of the class

• Services that objects of a class can provide to other objects

Class Diagram: Operations

• Operations describe what instances of a class can do:– Set or reveal attribute

values

– Perform calculations

– Send messages to other objects

– Create or destroy links

Campaign

actualCostcampaignFinishDatecampaignStartDatecompletionDatedatePaidestimatedCosttitlecheckCampaignBudget ( )getCampaignContribution ( )recordPayment ( )setCompleted ( )