Download
1 / 98
1k likes | 1.31k Views
UNIFIED PROCESS. What is Object Oriented Analysis?. The emphasis is on finding and describing real world the objects or concepts in the problem domain. In the course registration system, some of the concepts include : student , course , enrollment …etc. The Unified Process.
E N D
What is ObjectOriented Analysis? • The emphasis is on finding and describingreal world the objectsor concepts in the problem domain. In the course registration system, some of the concepts include : student , course , enrollment…etc.
The Unified Process • A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development. • The course, will focus on the Unified Process developed at Rational Software by Ivar Jacobsen, Grady Boch, Jim Rumbaugh, and others.
Applying UML • UML is just a standard diagramming notation. It is just a tool. • Knowing UML helps you communicate with others in creating software NB: Goal of this class: • Learning Object-Oriented Analysis and Design, not how to draw diagrams.
Why UP? • Think and Design with Objects • Apply UML • Use Design Patterns • Apply to Agile approaches (XP, scrum) • Incremental requirements analysis • Use cases
Phases in RUP (developed by Rational Corporation) RUP is divided into four phases: • Inception • Elaboration • Construction • Transition
Rational Unified Process Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 Iterations within phases
Most Important Concept in UP • The critical idea in the Rational Unified Process is Iterative, Incremental development. • Iterative Development is successively enlarging and refininga system through multipleiterations, using feedback and adaptation.
The Most Important Concept • Each iteration will include requirements, analysis, design, and implementation. • Iterations are timeboxed. • Incremental : system grows over time
Example: BuildingaHouse • Incremental: Start with a modest house, keep adding rooms and upgrades to it. • Iterative: On each iteration, the house is re-designed and built a new.
Iterations • Each iteration involves : • Choosing small subset of requirements. • Quick design, implementation and testing • User quickly see partial system • Rapid , early feedback ( ex: usability tests from users) • Yes , that´s exactly what I asked for …………. • I try it , what I really want is something slightely different… • Modify and Adapt understanding of the requirements or design , then involve the user again • Ex: Course registration system !!
Another approach :Waterfall Model All or most of the requirements are defined before development begins Requirements Design Implementation Test
Inception is not Requirement phasee Chapter 3 and 4 Applying UML and Patterns -Craig Larman
Do you remember this ? Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 time
Inception : Initial short step in the process What needs to be done? • Describe the initial common visionand business case for this project. • Exhibiting at least one candidate architecture • based on experience gained from similar systems or in similar problem domains • Determine if the project is feasible • Determine if the organization should buildorbuy the necessary system • Make a rough estimate of the cost and time . • Determine if we should go ahead with the project or stop
Example Questions in Inception Ask questions such as: • What is the vision and business case for this project? • Feasible? • Buy and/or build? • Buy components and glue them together or from scratch? • Estimate potential risks • Rough estimate of cost: Is it $10K-100K or in the millions? • Should we proceed or stop? If the answeris YES …..
Feasible ? Legal feasibility No conflicts with legal requirements, e.g. a data processing system must comply with the local Data Protection Acts.. Schedule feasibility Schedule feasibility is a measure of how reasonable the project timetable is. Given our technical expertise, are the project deadlines reasonable? Cultural feasibility Impact on the local and general culture Resource feasibility
Use Cases • Use cases are stories of how actors use (intercat with) the system to fulfill his goal. • Use cases are ‘tasks’ done by the system and has observable value to the actor • Process sale • Place Order • Loan book
Use Case 1 • Use case • is a collection of related success and failure scenarios that describe an actor using a system to support a goal. • be text documents, not diagrams • Use case modeling is primarily an act of writing text, not drawing diagrams. • There is nothing object-oriented about use cases; • Use cases are a key requirements input to classic OOA/D. • be functional or behavioral requirements that indicate what the system will do.
The purpose of use cases • Uncover and describe all tasks that need doing in a system (of both human and system actors) • Give a clear and consistent description of what the system should do. • Provide a basis for performing tests that verify the system delivers the functionality stated. • To analyse what functionality that need developing for the system • The use of use cases must mean that the right functional requirements are made of the IT system (the requirements of the business!)
Use cases documented in two ways • Use Case diagrams • Give an overview of visible use scenarios in the system • Describes what actors that interact with the system • Describes any linkages between use cases • Verbal description • Describes the content of each use case • Typically uses a pre-defined template
Use Case Formats Use case can be written in # formats : • Brief • Terse one-paragraph summary, usually the main success scenario. • During early requirements analysis • Casual • Informal, multiple paragraphs that cover various scenarios. • During early requirements analysis • Fully dressed • The most elaborate. All steps and variations are written in detail and there are supporting sections with preconditions etc. • After many use cases have been identified and written in brief format (already in inception 10 - 20% of use cases)
Actors - stakeholders • Actor: external entity interacts (behavior) with system, such as a person (identified by role), computer system, or organization; for example, a cashier. • Three kind of Actors - Stakeholders • Primary actor has user goals fulfilled through using services. (e.g., the cashier). • Supporting actor provides a service (e.g., the automated payment authorization service is an example). Often a computer system, but could be an organization or person (external interfaces) (e.g. : tax calculation ) • Offstage actor has an interest in the behavior of the use case, but is not primary or supporting (e.g., a government tax agency).
How to find Use cases ? • Recommended procedure: • Choose the system boundary • Find the primary actor • Find the user goals • Define a use case for each • How? • Ask: what are your goals? (Instead of what do you do?)
Use case diagram Actor (person) Actor (system) use case
Domain Model Chapter 9 Applying UML and Patterns -Craig Larman
What is a Domain Model? • Problem domain : area (scope)of application that needed to be investigated to solve the problem • Domain Model : Illustratesmeaningful conceptual objects inproblemdomain. • So domain model are conceptual objects of the area of application to be inestigated
Domain model representation? • A domain model is a visualrepresentation of real worldconcepts(real-situation objects ), thatcouldbe : idea, thing , event or object…..etc . • Business objects- represent things that are manipulated in the business e.g. Order. • Realworldobjects – things that the business keeps track of e.g. Contact , book. • Events that transpire - e.g. sale, loan and payment. • Not of software objects • Is part of business Model artifact (document)
Domain Model - UML Notation • Illustrated using a set of domain objects (conceptual classes) with no operations ( no responsibility assigned yet , this will be assigned during design).
Method1: NounPhraseIdentification • Identify Nouns and Noun Phrases in textual descriptions of the domain that could be : • The fully dressed Use Cases • The problem definition. But not strictly a mechanical process. Why ? • Words may be ambiguous ( such as : System ) • Different phrases may represent the same concepts.
Main Success Scenario (or Basic Flow): • 1. Customer arrives at POScheckoutwith goods and/or services to purchase. • 2. Cashier starts a new sale. • 3. Cashier enters itemidentifier. • 4. System records salelineitem and presents item description, price, and running total. • Price calculated from a set of price rules. • Cashier repeats steps 3-4 until indicates done. • 5. System presents total with taxes calculated. • 6. Cashier tells Customer the total, and asks for payment. • 7. Customer pays and System handles payment.
8. System logs completed sale and sends sale and payment information to the external accountingsystem (for accounting and commissions) and Inventorysystem (to updateinventory). • 9. System presents receipt. • 10. Customer leaves with receipt and goods (if any). • Extensions (or alternative Flows) • 7a. Paying by cash: • 1. Cashier enters the cash amount tendered. • 2. System presents the balancedue, and releases the cash drawer. • 3. Cashier deposits cash tendered and returns balance in cash to Customer. • 4. System records the cashpayment.
Method2 : By Category List (read p 140-141) Common Candidates for classes include: • Descriptions , Roles , Places , Transactions • Containers , Systems , abstract nouns , Rules • Organizations, Events, Processes, catalogs , Records , services.
Fig. 9.12 Association: Relationship between classes (more precisely, between instances of those classes)indicatingsomemeaningfulandinterestingconnection
Chap 11Operation Contracts Chapter 11 Applying UML and Patterns -Craig Larman
Operation Contract • Operation contract identifies system state changes when an operation happens. • Define what each system operation does • An operation is a single event from the system sequence diagram • A domain model is used to help generate an operation contract
Operation Contract • When making an operation contract, think of the state of the system before the action and the state of the system after the action. • The conditions both before and after the action should be described in the operation contract. • The pre and post conditions describe state, not actions.
Sections of an Operation Contract • Operation: Name of the operation and parameters • Cross References: Use cases and scenarios this operation can occur within • Preconditions: Noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation. • Postconditions:This is the most important section. The state of objects in the Domain Model after completion of the operation
Postconditions: most important • Describe changes in the state of objects in the domain model after completion of the operation • what instances were created ? • what associations were formed/broken? • what attributes changed? • Are not actions to be performed during the operation
Examples of Operation Contracts From Process Sale Use Case
Main Success Scenario (or Basic Flow): • 1. Customer arrives at POS checkout with goods and/or services to purchase. • 2. Cashier starts a new sale. • 3. Cashier enters item identifier. • 4. System records sale line item and presents item description, price, and running total. • Price calculated from a set of price rules. • Cashier repeats steps 3-4 until indicates done. • 5. System presents total with taxes calculated. • 6. Cashier tells Customer the total, and asks for payment. • 7. Customer pays and System handles payment.
