Upload
chad-bridges
View
225
Download
2
Tags:
Embed Size (px)
Citation preview
Software EngineeringSoftware Engineering
Object Oriented Analysis
ObjectivesObjectives
To outline an Object Oriented Analysis process and modelling language
To study the process and notation associated with use-cases
To provide an example of use-cases in action
[1] Object Oriented Analysis[1] Object Oriented Analysis
Get from real world domain
Decomposed into process (algorithm) and models (output of algorithm)
ProcessProcess
The steps taken in order to complete an analysis (the algorithm)
The OOA process landscape: Booch: evolutionary process encompassing both a ‘macro’ and
‘micro’ development process Rumbaugh: OMT (Object Modeling Technique) producing object,
dynamic and functional models Jacobson: OOSE (Object Oriented Software Engineering)
emphasises Use-Cases Coad and Yourdon: Viewed as one of the easiest Wirfs-Brock: No clear distinction between analysis and design
BUT All similar with small annoying differences. Booch, Rumbaugh and Jacobson now combined (Objectory
process)
Generic ProcessGeneric Process
Most OOA processes have the following steps in common:1. Elicit customer requirements
2. Identify scenarios or use-cases
3. Extract candidate classes
4. Identify attributes and methods
5. Define a class hierarchy
6. Build an object-relationship model
7. Build an object-behaviour model
8. Review the OO analysis against the use-cases
9. Repeat as required
Modeling LanguageModeling Language
A modeling language is a means of specifying, visualizing and documenting the artifacts of a software systems.
These models are the primary means of communication between users and developers
Modeling languages specify a notation
It is important that they be standardized
Unified Modeling Language (UML)Unified Modeling Language (UML)
A notational System (including semantics for its notations) that is principally graphical and aimed at modeling systems using object oriented concepts.
UML is not a process, methodology or proprietary Combines the notations of Booch, Rumbaugh and Jacobson Standardized by the OMG (Object Management Group) Defines a notation (syntax) and a meta-model (defining the
notation using the notation) Consists of:
Views (shows different faces of the system and links with the process)
Diagrams (graphs that describe the contents of a view) Model elements (concepts used in a diagram)
ViewsViews
User model view. This view represents the system (product) from the user’s (called “actors” in UML) perspective.
Structural model view. Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled.
Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the system.
Implementation model view. The structural and behavioral aspects of the system are represented as they are to be built.
Environment model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented.
Analysis = Process + ModelsAnalysis = Process + Models
Process Model Output
1. Elicit customer requirements and identify use-cases
Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy
Class Responsibility Collaborator (CRC) Cards
3. Build an object-relationship model
Class Diagram
4. Build an object-behaviour model
Interaction Diagram
[2] Use Cases[2] Use Cases
a view of a system that emphasizes the behavior as it appears to outside users. A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’).
A use-case scenario is a typical interaction between a user and a computer system (a thread of usage of a system)
Properties: Captures some user-visible function Achieves a discrete goal for the user No attempt to represent order or number of times actions are executed
Captured (in the simplest usage) by talking to a typical user and discussing what they want to achieve with the system.
Use-cases can be used to derive structural and behavioural models and construct test cases.
Use Case DiagramsUse Case Diagrams
Graphically shows use-cases, actors and their relationships.
Use CaseCommunication
Relationship
Actor
Analyze Risk
Trader
Price Deal
Capture Deal
Valuation
Limits Exceeded
<<extends>>
<<uses>>
<<uses>>
Uses Relationship
Extends Relationship
Use CasesUse Cases
Fundamentally a system transaction
Arranged in a hierarchy. At the top level a system box can
enclose the use-cases
At lower levels each use-case isdecomposed into several moredetailed use-cases
Use cases often start with a verb in order to emphasize that they are processes (Buy Items, Price Deal)
Valuation
Share Trade System
ActorsActors
actors represent roles people or devices play as the system functions. They communicate with the system and are external to it.
users can play a number of different roles for a given scenario. Example: an operator on a production line might have many roles
(programmer, tester, monitor, troubleshooter). Each of these would represent an actor in the use-case
A single actor may perform many use-cases; a use-case may have several actors performing it
System (non-human) actors should only be shown when they are the ones that need the use case Example: If the system generates a file that is later picked up by
the accounting system then the accounting system is a relevant actor.
Trader
RelationshipsRelationships
Communication: Flow of data and control between an actor and use-case
Uses: Use uses when you are repeating yourself in two or more
separate use cases and you want to avoid repetition
Extends: Use extends when you are describing a variation on
normal behaviour
Useful for identify core and extended functionality
<<uses>>
Use Case Narratives Use Case Narratives
For each use-case provide a narrative document
For example:
Use Case: Buy Item
Actors: Customer, Cashier
Description:
- The use case begins when the customer arrives at a checkout with items to purchase.
- The Cashier records each item. If there is more than one of an item, the Cashier can enter the quantity as well.
- The system determines the item price and adds the information to the running sales transaction. The description and price of the current item are presented.
- On completion of item entry, the cashier indicates that item entry is complete.
- The system calculates and presents the sale total.
Developing a Use CaseDeveloping a Use Case
Ask yourself these questions: What are the main tasks or functions that are
performed by the actor?
What system information will the the actor acquire, produce or change?
Will the actor have to inform the system about changes in the external environment?
What information does the actor desire from the system?
Does the actor wish to be informed about unexpected changes?
Modeling TipsModeling Tips
Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers
When defining use cases in text, use nouns and verbs accurately and consistently to help with later derivation of objects.
A use case diagram should contain only use cases at the same level of abstraction
include only actors who are required
Try to describe use cases independent of implementation
A use case can have many scenarios (threads of execution)
[3] A Use-Case Example [3] A Use-Case Example
Example: Home Security System (SafeHome)
Project Brief (provided at the start of the project): Build a micro-processor based home security system
that will protect against and/or recognize a variety of undesirable situations such as illegal entry, fire and flooding.
The product will use appropriate sensors to detect each situation, can be programmed by the homeowner and will automatically telephone a monitoring agency when necessary.
Actors: homeowner (the user) sensors (devices attached to the system) monitoring and response subsystem (central station that
monitors SafeHome)
Interactions (for the Homeowner): Enters a password to allow all other interactions Inquires about the status of a security zone Inquires about the status of a sensor Presses the panic button in an emergency Activates/deactivates the security system
Actors and Interactions Actors and Interactions
Use-Case DiagramsUse-Case Diagrams
(a) High-Level
(b) Intermediate LevelInteracts expanded
Use-Case NarrativeUse-Case Narrative
Use-Case: Activates System Users: Homeowner Description:
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].
The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors. Away activates all sensors.
When activation occurs, a red alarm light can be observed by the homeowner.