Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Object-Oriented Analysis and Design. Priorities in O-O Analysis and Design Understanding a system in terms of objects and associations between them. Representing."— Presentation transcript:

1 Object-Oriented Analysis and Design

2 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.

3 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

4 “Official” representation of RUP Source: http://www.rational.com

5 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)

6 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?)

7 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)

8 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

9 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

10 Class Diagram: Class Symbol Client companyAddress companyEmail companyFax companyName companyTelephone Class name compartment Attributes compartment Operations compartment

11 Class Diagram: Instance Symbol FoodCo:Client companyAddress=Evans Farm, Norfolk companyEmail=mail@foodco.com companyFax=01589-008636 companyName=FoodCo companyTelephone=01589-008638 Object name compartment Attribute values Instances do not have operations

12 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

13 Class Diagram: Associations StaffMember staffName staffNo staffStartDate Client companyAddress companyEmail companyFax companyName companyTelephone liaises with staffContact Association role Association Association name Direction in which name should be read

14 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

15 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

16 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

17 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

18 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 actualCost campaignFinishDate campaignStartDate completionDate datePaid estimatedCost title checkCampaignBudget ( ) getCampaignContribution ( ) recordPayment ( ) setCompleted ( )


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

Similar presentations


Ads by Google