software engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Engineering PowerPoint Presentation
Download Presentation
Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 21

Software Engineering - PowerPoint PPT Presentation


  • 65 Views
  • Uploaded on

Software Engineering. Object Oriented Analysis. Objectives. To explain Class-Responsibility-Collaborator Modelling. To provide an example of CRC modelling in action. Analysis = Process + Models. Class-Responsibility-Collaborator Modelling.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Engineering' - felcia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software engineering

Software Engineering

Object Oriented Analysis

objectives
Objectives
  • To explain Class-Responsibility-Collaborator Modelling.
  • To provide an example of CRC modelling in action
class responsibility collaborator modelling
Class-Responsibility-Collaborator Modelling
  • A simple means of identifying and organizing classes
  • Not an official part of UML
  • A CRC model is a collection of index cards that represent classes
  • Each CRC card contains:
    • Class name, type, characteristic
    • Responsibilities
    • Collaborations
  • Index cards because they can only hold a limited amount of information  enforces high-level analysis
  • Steps in CRC modelling: Identify [1] Classes, [2] Responsibilities, [3] Collaborators, [4] Review the Model
crc benefits
CRC Benefits
  • They are portable. No computers are required so they can be used anywhere. Even away from the office.
  • They allow the participants to experience first hand how the system will work.
crc cards
CRC Cards

class name:

class type: (e.g., device, property, role, event, ...)

class characteristics: (e.g., tangible, atomic, concurrent, ...)

responsibilities:

collaborators:

1 identifying classes
[1] Identifying Classes
  • Classes and Objects are extracted from the Use-Cases by doing a grammatical parse
  • Grammatical Parse:
    • Underline nouns or noun clauses (these describe candidate objects)
    • Enter the candidate objects (and their associated classes) into a table
    • Remove synonyms
    • Solution Space: objects required to implement the solution
    • Problem Space: objects required to describe the problem
  • “The really hard problem [in OO] is discovering what are the ‘right’ objects in the first place”
accepting classes
Accepting Classes
  • Objects are accepted if they satisfy all (or almost all) of the following requirements:
  • Retained Information: the system needs to remember data about the object
  • Needed Services: the object must have an identifiable set of operations
  • Multiple Attributes: during analysis we focus on major information only. Objects should have many attributes
  • Common Attributes: A set of attributes apply to all occurrences of the object
  • Common Operations: A set of operations apply to all occurrences of the object
  • Essential Requirements: external entities that produce or consume essential information
class types
Class Types
  • Accepted classes are assigned a type:
  • External entities - other systems, devices, people
  • Things - reports, displays, signals
  • Occurrences or events - property transfer, completion of a series of robot movements
  • Roles - manager, engineer, sales person
  • Organizational Units - division, group, team
  • Places - manufacturing floor, loading dock
  • Devices - four-wheeled vehicles, computers
  • Property - of the problem, e.g. credit rating
  • Interaction - model interaction that occur among other objects, e.g. a purchase or a license
class characteristics
Class Characteristics
  • Accepted classes are assigned a set of characteristics:
  • Tangibility: does the class represent a tangible (physical) or abstract (information) entity?
  • Inclusiveness: is the class atomic (includes no other classes) or aggregate (has at least one nested object)?
  • Sequentiality: is the class concurrent (has its own thread of control) or sequential (scheduled by outside resources)?
  • Persistence: is the class transient (created and removed during program operation), temporary (created during program operation and removed at termination) or permanent (stored in a database)?
  • Integrity: is the class corruptible (does not protect its resources from outside influence) or guarded (the class enforces access control)?
example identifying classes
Example: Identifying Classes
  • Narrative:
    • SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHomecontrol panel.
    • During installation, the SafeHomecontrol panel is used to “program” and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.
  • Potential Objects/Classes
    • Homeowner, sensor, control panel, installation, system (alias security system), number, type, master password, telephone number, sensor event, …
example crc header

class name: Sensor

class type: external entity

class characteristics: tangible, atomic, concurrent, guarded

responsibilities:

collaborators:

Example: CRC Header
2 identifying responsibilities
[2] Identifying Responsibilities
  • Responsibilities (attributes and methods) are extracted from the Use-Cases descriptions
  • Attributes:
    • Describe the object
    • Select those things that reasonably belong to an object
    • Question: What data items fully define this object in the context of the particular use-case?
  • Methods (Operations):
    • Define the behaviour of the object and alter the object’s attributes
    • Types of operations – data manipulation, computation, event monitoring
    • Do a grammatical parse of the Use-Case description and isolate verbs
guidelines for allocating responsibilities to classes
Guidelines for Allocating Responsibilities to Classes
  • System intelligence should be evenly distributed.
  • Each responsibility should be stated as generally as possible.
  • Information and the behavior that is related to it should reside within the same class.
  • Information about one thing should be localized with a single class, not distributed across multiple classes.
  • Responsibilities should be shared among related classes, when appropriate.
example identifying responsibilities
Example: Identifying Responsibilities
  • Narrative:
    • SafeHome software enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through a keypad and function keys contained in the SafeHome control panel.
    • During installation, the SafeHome control panel is used to “program” and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.
  • Example Operations:
    • Assign (belongs to Sensor)
    • Program (belongs to System)
    • Arm/Disarm (belong to System)
example crc responsibilities
Example: CRC Responsibilities
  • Example Attributes:
    • sensor information = sensor number + sensor type + alarm threshold

class name: Sensor

class type: external entity

class characteristics: tangible, atomic, concurrent, guarded

responsibilities:

collaborators:

keep sensor information

assign sensor information

signal sensor event

3 identifying collaborators
[3] Identifying Collaborators
  • Collaborations represent requests from a client to a server in fulfillment of a client responsibility
  • One object collaborates with another if it needs to send a message
  • Relationships:
    • is-part-of (classes that are contained within an aggregate class as attributes)
    • has-knowledge-of (one class must acquire information from another)
    • depends-upon (dependency not covered by part-of or knowledge-of)
4 reviewing the crc model
[4] Reviewing the CRC Model
  • All participants in the review (of the CRC model) are given a subset of the CRC model index cards.
  • All use-case scenarios (and corresponding use-case diagrams) should be organized into categories.
  • The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card.
  • When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement.
  • If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.
example crc review
Example: CRC Review
  • Use-Case Narrative:
    • The homeowner observes the control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close window/doors so that the ready indicator is present [a not ready indicator implies that a sensor is open].
  • When review leader comes to “control panel” token is passed to the person holding the control panel CRC card.
  • Phrase “implies that a sensor is open” means a responsibility must validate this.
  • The control panel CRC card has sensor as a collaborator
  • The token is next passed to the sensor CRC card.
crc tips
CRC Tips
  • Don’t generate long lists of responsibilities. This is missing the point. The responsibilities should easily fit on a card.
  • The review stage is crucial. Spend a lot of time here.