You are on page 1of 15

GC22: Software Engineering

Object-Oriented Analysis

Professor David S. Rosenblum Department of Computer Science http://www.cs.ucl.ac.uk/staff/D.Rosenblum/

© 2007 David S. Rosenblum

Object-Oriented Analysis
Definition
Analysis facilitates the difficult transition between problem domain and solution domain, i.e., between the world and the machine

• It attempts to refine and structure requirements in a way
that allows the designer to begin reasoning about the internal workings of the envisaged system • It aims to separate concerns (i.e., to delineate the issues to be resolved and the decisions to be taken later on) • It assists planning an incremental approach to later workflow activities • The result is an initial high-level design model: the analysis model
Software Engineering (GC22)

© 2007 David S. Rosenblum

Object-Oriented Analysis
USDP Context
Elaboration Inception Construction Transition

Requirements

Analysis
Design

Implementation Test
Preliminary iterations iteration iteration iteration iteration iteration iteration #1 #2 #n #n + 1 #n + 2 #m iteration #m + 1

Software Engineering (GC22)

© 2007 David S. Rosenblum

Software Engineering (GC22)

1

Rosenblum Approach 1: Data-Driven Design Identifying Classes • Identify all the data in the system • Divide into classes before considering responsibilities • Common approach: noun identification  Identify candidate classes by selecting all the nouns and noun phrases in the requirements document  Discard inappropriate candidates » Redundant or omnipotent entities » Vague entities » Events or operations » Meta-language » Entities outside system scope » Attributes  Verbs and verb phrases highlight candidate operations! Software Engineering (GC22) © 2007 David S. Described in the language of the developer 2. Defines use case realisations (each an analysis of a use case in the use case model) © 2007 David S. Rosenblum 4. May contain redundancies and inconsistencies amongst requirements 6. Internal view of the system 3. Used primarily by developers to understand how to design & implement the system 5. External view of the system 3. Rosenblum Software Engineering (GC22) 2 . Defines use cases that are further analysed in the analysis model Software Engineering (GC22) Analysis Classes • An analysis class abstracts one or more classes and/or subsystems in the system’s design the class)  Focuses on handling functional requirements  Defines responsibilities (cohesive subsets of behaviour defined by  Defines attributes  Expresses relationships the class is involved in • Three basic kinds (according to Rational Unified Process)  Boundary classes  Control classes  Entity classes Software Engineering (GC22) © 2007 David S. Outlines a first-cut design 7. Captures system functionality 7. Used primarily as a contract between customers and developers 5. Analysis Models Jacobson et al. Described in the language of the customer 2.. Structured by use cases ANALYSIS MODELS 1.Use Case Models vs. Structured by stereotypical classes and packages 4. Should not contain redundancies or inconsistencies amongst requirements 6. 1999 USE CASE MODELS 1.

assign them to classes • Underline all the verbs and verb phrases • Create a list of candidate operations and assign them to the classes Software Engineering (GC22) © 2007 David S. Rosenblum Software Engineering (GC22) 3 . 2000 LibraryMember Responsibilities Maintain data about copies currently borrowed Meet requests to borrow & return copies Copy Responsibilities Maintain data about particular copy of book Inform corresponding Book when borrowed/returned Book Responsibilities Maintain data about one book Know whether there are borrowable copies Software Engineering (GC22) Collaborators Copy Collaborators Book Collaborators © 2007 David S. Rosenblum Approach 2: Responsibility-Driven Design Identifying Classes • Identify all the responsibilities in the system • Divide into classes before considering the classes’ data • Common approach: CRC cards  Class. you may also identify some candidate attributes  If so. Rosenblum Example CRC Cards for a Library Stevens & Pooley.Exercise • Go back to your requirements document and set of use cases for the library system  And anything else you might have gathered or created by now • Underline all the nouns and noun phrases • Create a list of candidate classes  In examining the discard criteria. Responsibilities. Collaborations Software Engineering (GC22) © 2007 David S.

Rosenblum UML Class Icons Optional Visibility Adornments (+public. ~package) Class name (in italics if abstract) Name compartment Optional attribute compartment Optional operation compartment } } } Book #title : String #available : Boolean = true <<constructor>> +create() +copiesOnShelf() : Int +borrow(c:Copy) Software Engineering (GC22) Attribute name Attribute type Initial value Operation with class scope and <<stereotype>> Operation signatures © 2007 David S. but then brainstorm the things operating in the library system domain  Accept all ideas at this point and write each as a candidate class on a separate card • Information analysis  Stick all cards on a wall and. #protected. -private. Rosenblum Software Engineering (GC22) 4 . try to determine responsibilities and collaborators Software Engineering (GC22) © 2007 David S. Rosenblum Example UML Class className attribute name: type Polygon centre : Point vertices: List of Point borderColour: Colour fillColour: Colour display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean operation name (parameter: type): result type className Software Engineering (GC22) Polygon © 2007 David S.Exercise • Go back to your requirements document and set of use cases for the library system  And anything else you might have gathered or created by now • Create a set of CRC cards using post-it notes • Information gathering: Use this material as a prompt. as a group.

Instance Scope versus Class Scope • Instance scope  By default. allowing different objects to have different values  Operations operate on specific instances of classes • Class scope  Attributes with class scope have a single shared value for every instance of the class  Operations with class scope don’t operate on class instances. attributes and operations in a class have instance scope  Objects have their own copies of attributes. Rosenblum What Makes a ‘Good’ Analysis Class? • Its name reflects its intent • It is a crisp abstraction that models one specific element of the problem domain • It has a small but defined set of responsibilities • It has high cohesion • It has low coupling with other classes Software Engineering (GC22) © 2007 David S. Rosenblum Software Engineering (GC22) 5 . Rosenblum Example UML Class Diagram Taken from [Booch 1999] Software Engineering (GC22) © 2007 David S. but on behalf of the entire class » Example: Constructors Software Engineering (GC22) © 2007 David S.

0). Rosenblum Software Engineering (GC22) 6 . Rosenblum Example UML Object Diagram Taken from [Booch 1999] Software Engineering (GC22) © 2007 David S. (4.UML Object Icons Object name Name compartment Optional attribute compartment Class name } } DSRsUMLBook : Book title = “Using UML” Attribute name Attribute value Operations and attribute types are not shown on object diagrams! Software Engineering (GC22) © 2007 David S.3) borderColour = black fillColour = white (same operations for all instances of a class) display (on: Surface) rotate (angle: Integer) erase () destroy () select (p: point): Boolean objectName: className Software Engineering (GC22) triangle1: Polygon © 2007 David S.0). Rosenblum Example UML Object objectName: className attribute name: type = value triangle1: Polygon centre = (0. (4.0) vertices = (0.

describing how objects work together • Associations are relationships between classes  Examples » Object » Object » Object » Object  Act as a sanity check for good modelling • Links are relationships between objects  Links can be instances of associations of of of of class class class class A A A A sends a message to object of class B creates an object of class B has attribute whose values are objects of class B receives a message with argument of class B  Allow one object to invoke operations on another object Software Engineering (GC22) © 2007 David S.Exercise • Compare the results of using noun identification and CRC cards for identifying candidate classes in the library system • Construct a class diagram (using the basic notation) to combine the consolidated results of using the two techniques: a first cut analysis model Software Engineering (GC22) © 2007 David S. Rosenblum Software Engineering (GC22) 7 . Rosenblum Relationships • Relationships are connections between modelling elements  Improve understanding of the domain. Rosenblum UML Relationship Notation bidirectional / binary navigability unidirectional navigability aggregation composition association name [+ single directional arrow] role name multiplicity role name multiplicity Software Engineering (GC22) supplementary characteristics © 2007 David S.

* Meaning Zero or 1 Exactly 1 Zero or more 1 or more 1 to 5 1 to n 1 to 3 OR 8 to 10 OR 15 to many Software Engineering (GC22) © 2007 David S..1 1 0.....* 0.. 8..5 1..10.* or * 1.1 borrows/returns borrows/returns 0.n 1.3.* Journal © 2007 David S..* Book is copy of 1 1.Links Instantiate Associations LibraryPatron borrows Book Class and Association Level <<instantiate>> <<instantiate>> <<instantiate>> DSR:LibraryPatron usingUML: Book Object and Link Level Software Engineering (GC22) © 2007 David S.* LibraryPatron Copy 0. 15..* 1.1 0.. Rosenblum Software Engineering (GC22) 8 .... Rosenblum Some Ways to Specify Multiplicity Syntax 0. Rosenblum Multiplicity of an Association • Indicates the number of objects that can participate in a relationship at any point in time borrows/returns 0..1 Software Engineering (GC22) MemberOfStaff 0.

. named associations.Exercise • Using your initial analysis class diagram for the library  Consider the interactions in your earlier use cases  Consider the CRC cards you produced and the listed collaborators system.. Rosenblum Generalisation and Inheritance • A special kind of association • Subclass inherits attributes and operations of superclass  And possibly extends superclass Book is copy of Copy 0. identify and add associations between the classes • Add associations to your class diagram and provide each with  a name  multiplicity  navigability • Your analysis model should now show classes. attributes.* Journal © 2007 David S...1 borrows/returns borrows/returns 0..* 1 1. Rosenblum Software Engineering (GC22) 9 ..1 0.1 Software Engineering (GC22) Researcher 0.* LibraryPatron Superclass borrows/returns 0. operations. Rosenblum Another Inheritance Example Abstract class Staff Member salary: Int increaseSalary(Int) salary: Int increaseSalary(Int) Librarian assignSubject(String) Tutor assignCourse(String) Researcher beginProject(String) salary: Int increaseSalary(Int) assignCourse(String) beginProject(String) Multiple inheritance Professor Software Engineering (GC22) © 2007 David S. multiplicity and navigability Software Engineering (GC22) © 2007 David S..* Subclass 0.

Rosenblum Association Classes • Used to attach attributes to an association itself rather than the classes it associates • Class association line must have the same name! Student is taking 1. so the parts cannot feature elsewhere CheckerBoard 1 64 Square • NOTE: Not all 1-to-* relationships imply ownership Software Engineering (GC22) © 2007 David S..Part/Whole Associations • Aggregation: Weak Ownership  The part objects can feature simultaneously in any number of other whole objects Course 1.* Module • Composition: Strong Ownership  The whole strongly owns its parts. Rosenblum Software Engineering (GC22) 10 .* 5 Module is taking mark : int Software Engineering (GC22) Association class © 2007 David S.* 5. indicating that they will not be implemented Student takes /is taken by Module /teaches /is taught by teaches Lecturer Software Engineering (GC22) © 2007 David S... Rosenblum Derived Associations • Is it necessary to show all associations?  Sometimes associations that are not explicit can be deduced from the diagram  They can be reprsented explicitly as derived associations.

no behaviour (other than those they contain) • Packages primarily serve to provide a namespace  Like Java packages  Entities are identified using qualified names » Package name::package element » Example (class attribute): Travel Agency::Agent::customerArray » Example (operation): Library::BookBorrower::borrow(Copy) Software Engineering (GC22) © 2007 David S. multiplicity and navigability) • Update your model if there is anywhere you can apply  Inheritance  Association classes  Qualified associations  Other dependencies Software Engineering (GC22) © 2007 David S. the one that shows classes. Rosenblum Package Diagrams Description • Package Diagrams are general purpose mechanisms for organising model elements into related groups  But they have no realisation in the modelled system » No interfaces. Rosenblum Architectural Analysis • Architectural analysis involves organising analysis classes into packages  Analysis classes  Use case realisations • Key criterion: Separation of Concerns  High cohesion within packages  Low coupling between packages NOTE: This is a rather inadequate ‘big picture’ notion of architecture that weakly accounts for system structure Software Engineering (GC22) © 2007 David S. named associations. attributes.e. operations..Exercise • Examine your updated analysis model (i. Rosenblum Software Engineering (GC22) 11 .

but also finding use case realisations • Use case realisations show how analysis classes collaborate to realise the behaviour specified by the use case • Each use case has a use case realisation Software Engineering (GC22) © 2007 David S. Rosenblum Use Case Realisation Description • Analysis class diagrams  Relationships between analysis classes that interact to realise the use case • Interaction diagrams  Example collaborations between objects realising the use case at moments in time • Special requirements  Realisation process helps uncover new requirements • Use case refinement  Realisation helps update understanding of original use cases Software Engineering (GC22) © 2007 David S. Rosenblum Use Case Realisation Description • Analysis not only involves finding analysis classes. Rosenblum Software Engineering (GC22) 12 .Package Diagrams Example Library Book Personnel Librarian LibrarySearch Title Author <<imports> BookBorrower Software Engineering (GC22) © 2007 David S.

in detail.1 :borrowed theLibraryMember : LibraryMember theCopy : Copy 3 :borrow 2 :okToBorrow Software Engineering (GC22) © 2007 David S.0  Sequence Diagrams  UML 2.4 » Called Communication Diagrams in UML 2. Rosenblum Collaboration Diagram Example theBook : Book aMember : BookBorrower 1: borrow(theCopy) 3.0 also introduces Interaction Overview diagrams to show flow relationships between individual interaction diagrams © 2007 David S. Rosenblum Interaction Diagrams Modelling Elements • Collaboration Diagrams  Objects: Computer entities participating in an interaction  Actors: Users participating in an interaction  Links: Communication paths between objects and actors  Messages: Interaction instances between pairs of objects/actors • Sequence Diagrams » Ordered explicitly via message numbering  Objects: Computer entities participating in an interaction  Actors: Users participating in an interaction  Lifelines: Time-oriented representation of object/actor behaviour  Focus of Control: Portion of lifeline having active computation  Messages: Interaction instances between pairs of objects/actors » Ordered implicitly in sequence along lifelines Software Engineering (GC22) © 2007 David S. how objects interact to perform a task  Dynamic views of a system • Mainly used to show how a system realises a use case (or a • Two types particular scenario in a use case)  Collaboration Diagrams • The two types show almost identical information. so choice depends on modelling perspective Software Engineering (GC22) » More prominent in UML 1.Interaction Diagrams Description • Interaction diagrams record. Rosenblum Software Engineering (GC22) 13 .

Collaboration Diagram Example Taken from [Booch 1999] Software Engineering (GC22) © 2007 David S. using UML syntax. Rosenblum Sequence Diagram theLibraryMember : LibraryMember aMember : BookBorrower borrow(theCopy) okToBorrow borrow theCopy : Copy theBook : Book Example borrowed Software Engineering (GC22) © 2007 David S. create a collaboration diagram to realise it • Update your analysis class diagram accordingly Software Engineering (GC22) © 2007 David S. Rosenblum Software Engineering (GC22) 14 . Rosenblum Exercise • Create collaboration diagrams to illustrate how classes in your analysis model for the library system support functionality specified in the use cases • Start by selecting a simple use case and.

take each use case for your library system and create either a collaboration diagram or sequence diagram that realises the use case » Aim to practice both techniques evenly  Update your analysis class diagram accordingly Software Engineering (GC22) © 2007 David S.Sequence Diagram Example Taken from [Booch 1999] Software Engineering (GC22) © 2007 David S. 1995 Class diagrams and interaction diagrams contribute to this Design view (logical) Implementation view Use case view Interaction diagrams contribute to this Process view Deployment view © 2007 David S. Rosenblum Exercise • Take the collaboration diagram you have created for part of your library system • Turn this diagram into a sequence diagram • Then  In turn. Rosenblum Software Engineering (GC22) Software Engineering (GC22) 15 . Rosenblum The 4+1 View Model of Architecture Kruchten.