Object Oriented Analysis and Design Using the UML
Object Oriented Analysis and Design Using the UML Use Case Analysis Modified considerably by your Instructor OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 1/29
Objectives: Use-Case Analysis w Understand the purpose of Use-Case Analysis and where in the lifecycle it is performed w Identify the classes needed to accommodate a use- case flow of events (Analysis Classes) w Distribute the use-case behavior to those classes, identifying responsibilities of the classes w The analysis classes and the initial use-case realizations are the key model elements that we develop in this activity. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 2/29
Use Case Analysis w The focus during Use-Case Analysis is on a particular use case. w In Use-Case Analysis, we identify the analysis classes and define their responsibilities. § (At this time, we speak of ‘responsibilities. ’ (May even use the term, ‘services. ’) Later, these might become ‘methods’ or ‘member functions. ’ But that is a matter for implementation NOT initial design. ) w The allocation of responsibility is modeled in use -case realizations that describe how analysis classes collaborate to perform (realize) use cases. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 3/29
Use-Case Analysis Overview Use Case Analysis is performed By the Designer – once per Iteration per use case realization Software Architecture Document – (don’t Supplementary Glossary Specifications really have this one yet. ) Analysis Classes Use-Case Modeling Guidelines Use-Case Analysis Use-Case Realization (developed) Use-Case Model Design Model OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Analysis 4/29 Model (optional)
Use Case Analysis - Purpose w To identify analysis classes which perform a use case’s flow of events w To distribute the use case behavior to those classes § § Remember: domain entities do not contain behaviors… Use case analysis result in logical abstractions with attributes and behaviors. w To identify the responsibilities, attributes and associations of the classes w Input Artifacts – see previous slide w w w Output Artifacts: Analysis Classes Analysis Model Partially Developed Use-Case Realizations Work toward Design Model (first cut, really) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 5/29
Use-Case Analysis Steps – Major ones w 1. Supplement the Use-Case Description § Will be changing some as we continue to examine our Use Cases and add alternative, exception, and other flows. § We modify as we learn more and analyze… w 2. For (each use-case realization) Do: § Study Use Case flow of events - identify analysis classes from the Use Case narrative. These consist of interface, control, & data classes. § Allocate behaviors (responsibilities) to these classes. • These are the little things the class must do…. in some cases, these are merely options afforded to the user like add new customer() or delete customer ()…. display customer profile… § Distribute Use-Case Behaviors to Classes that you identify § Describe Attributes (properties) of each analysis class. § Show associations between the collaborating classes. w Let’s look at each of these two 6/29 major items in particular…. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Use-Case Analysis Steps w 1. Supplement the Use-Case Description § Capture additional information in order to understand the required internal behaviors. § It is quite customary to make changes (or should be…. ) § This is part of the iterative process. Versioning of Use Cases. § This is why we spend so much time on getting those use cases right – recall, Use Cases drive the whole shooting match! § Update / collapse flows of events as needed § But this is difficult to do. Consider OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 7/29
Supplement the Use-Case Description Sometimes the description of the use case is not sufficient for identifying analysis classes and their objects. Remember, customer (who should be the responsible person for the use cases) doesn’t care about the inside of the system, so many details may have been left out – leaving the use case description like a black box. Many times we do not have enough detail. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved • The system displays a list of course offerings. 8/29 • The system retrieves and displays a list of current course offerings from the course catalog legacy database given specific parameters, such as. . .
Use-Case Analysis Steps w 1. Supplement the Use-Case Description w 2. For (each use-case realization), Do: § Find Classes from Use-Case Behavior § May be easier now to identify our candidate analysis classes for the system • (candidate means ‘first cut; ’ ‘possible’ classes) • Identify a set of candidate analysis classes capable of performing the behaviors (actions; ‘verbs’) described in the use case. • These are ‘responsibilities’ of these classes. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 9/29
Find Candidate Classes from Behavior (1 of 2) w Will use three ‘divisions of responsibilities’ of the system to identify these classes. w Look for Classes that form: § The ‘boundary’ between the system and its actors § The ‘information’ the system uses § The ‘control logic’ of the system w Will use ‘stereotypes’ to represent these classes. § (These are conveniences used during analysis some of which will disappear or be transitioned into different design elements during the design process when some of these classes become design or software classes. . ) § This approach leads to a more robust design, as these things are likely to change during design. This way we can isolate them according to their use in the application. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 10/29
Find Classes From Use-Case Behavior w The complete behavior of a use case must be distributed to analysis classes w We must ‘identify’ these classes – give a name and briefly describe what they do in a few sentences. <<boundary>> <<control>> <<boundary>> <<entity>> OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 11/29
Kinds of Analysis Classes w The boundary between the system and its actors (interfaces… to end-users, external systems, devices…) w The information a system uses (data), and w The control logic of the system (who does what) w So, we isolate the different kinds of concerns and use analysis classes to capture these responsibilities. w Each category of analysis class has a typical set of duties & responsibilities 12/29 OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
What is an Analysis Class? Can use with the name of the stereotype In angle brackets or as symbols with unique icons. <<boundary>> Finding a candidate set of classes is the first part of transforming a mere statement of required behavior in a use case to a description of how the System will work. So, we start with Analysis Classes. System boundary Use-case behavior coordination System information OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved <<control>> <<entity>> 13/29
Analysis Classes – an Early Conceptual Model w The analysis classes, taken together, represent an early conceptual model of the system. w This conceptual model evolves quickly and remains fluid for some time as different representations and their implications are explored. (Consider boundary classes that form a user interface…) w Analysis classes rarely survive into the design unchanged. (But some do!) Don’t spend a lot of time here. § Analysis classes allow us to distribute responsibilities some of which will be later reallocated. w Many analysis classes represent whole collaborations of objects OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 14/29
Analysis Classes: A First Step Towards Executables Use Cases Analysis Design Classes Elements Source Code Use-Case Analysis OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved (…from 15/29 a structural perspective; static) Exec
What is a Boundary Class? w Insulates the system from changes in the outside w Three types of Boundary Classes § 1. User interface classes – classes that facilitate communication with human users of the system • Menus, forms, windows, etc. User interface classes…. § 2. System interface classes – classes which facilitate communications with other systems. Very Important! • These boundary classes are responsible for managing the dialogue with the external system, like getting data from an existing database system or flat file… • Provide an interface to that system (like a VSAM file) § 3. Device Interface Classes – provide an interface to devices which detect external events – like a sensor or … One boundary class per use case/actor pair Analysis class stereotype OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved <<boundary>> 16/29
The Role of a Boundary Class • Actors can only communicate with boundary classes <<boundary>> • Boundary classes identify the system’s boundaries. <<control>> <<boundary>> Customer External Database << boundary>> <<entity>> • Boundary class - used to model interaction between system’s surroundings and its inner workings. • Boundary Classes model parts of the system that depend on its surroundings. • Entity and control classes model parts that are independent of system’s surroundings. . Examples of boundary classes: Classes that handle GUI or communications protocols. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 17/29
Boundary Classes - more w Identify boundary classes for actor interactions mentioned in the flow of events of the use-case w Consider the source for all external events and make sure there is a way for the system to detect these events (user inputs/responses, connecting to an external file, detecting a buzzer, detecting a thermostat value. . . w Heuristic: initial identification of boundary classes: one boundary class per actor/usecase pair. § OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 18/29
Example: Finding Boundary Classes w One boundary class per actor/use case pair: Student Register for Courses Course Catalog System Two boundary classes: <<boundary>> Register. For. Courses. Form <<boundary>> Course. Catalog. System • The Register. For. Courses. Form contains a Student's "schedule-in-progress". It interfaces with the actor and displays a list of Course Offerings for the current semester from which the Student may select specific courses to be added to his/her Schedule. (Note that this description comes directly from the use case specification. We capture that behavior and encapsulate it (for now) into a boundary class with this description. ) • The Course. Catalog. System interfaces with the legacy system that provides the unabridged catalog of all courses offered by the university. 19/29 OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Boundary Class – As a User Interface class w 1. Concentrate: what information is presented to user § Do NOT concentrate on the UI details (windows, forms…) § Analysis Classes are meant to be a first cut at the abstraction of the system. § The boundary classes may be used as ‘holding places’ for GUI classes. (Addressed in more detail later in design) § Do not do a GUI design in analysis, but isolate all environment -dependent behavior. (Likely you may be able to reverse engineer a GUI component and tailor it. ) § If prototyping the interface has been done, these screen dumps or sketches may be associated with a boundary class. § Only model the key abstractions of the system like a form or profile…– not every button, list, etc. in the GUI. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 20/29
Boundary Classes – As External System and Device classes w 2 -3. System and Device Interface Classes § Concentrate on what protocols must be defined • Note that your application must interface with an existing information source, like a RDBMS. . . § Do NOT concentrate on how the protocols will be implemented! Merely note that there is an interface. w If the interface to an existing system or device is already well-defined, the boundary class responsibilities should be derived directly from the interface definition. w If there is a working communication with the external system or device, make note of it for later reference during design. (This is more than likely the case…) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 21/29
What is an Entity Class? (recall: boundary, entity, control…) Key abstractions of the system (What does that mean? ) Analysis class stereotype Sources for entity <<entity>> Glossary Classes: Glossary Use-Case Flow of Use Case Events Domain Model Business-Domain Model things…… Architectural Analysis Abstractions OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Entity classes show the logical data structure, which will help us understand what the system is supposed to offer to its users. Environment Independent 22/29
Entity Classes w Represent stores of information in the system w Used to represent the key concepts the system manages. (Core Abstractions) w The main responsibilities of entity classes are to store and manage information in the system. w Entity objects (instances of entity classes) hold and update information on some phenomenon, such as an event, a person, or some real-life object. § (Chapter advisor, memorabilia, university, student, correspondence_item, International_Secretary, Provider, Worker, account, inventory-item, …) § What are the ‘nouns’ in the use-case specification? ? w Often persistent; may well come from domain model (business entities) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 23/29
The Role of an Entity Class <<boundary>> Entity objects can have complicated behavior; however, unlike other objects, this behavior is strongly related to the phenomenon the entity object represents. <<control>> <<boundary>> Customer <<boundary>> Entity objects are usually not specific to one use-case realization; <<entity>> The values of an entity object and their relationships are often given by an actor. Entity objects are independent of the environment (actors) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 24/29
Example: Finding Entity Classes w Use use-case flow of events, the domain model, and glossary as inputs. § The more of these you have the better you are! w Traditional, filtering nouns approach (but I’d recommend using classes from the domain model (business entities) as a starting place, if available) § § § Underline noun clauses in the use-case flow of events Remove redundant candidates; Lots of synonyms! Remove vague candidates Remove actors (out of scope) Remove implementation constructs Remove attributes (save for later) • Lots of times, candidate ‘nouns’ may become ‘attributes’ in classes. (e. g. Student, gpa, major …) § Remove operations 25/29 OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Example: Candidate Entity Classes w Register for Courses Use Case § Specific scenario? Likely, Create Schedule. Student Course. Offering A person enrolled in classes at the university A specific offering for a course including days of week and times Schedule The courses a student has selected for current semester Note: these are candidate (analysis) entity classes only. So far, they do not possess responsibilities, attributes, associations, etc… 26/29 OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Candidate Entity Classes – Actors – same name? w Sometimes there’s a need to model information within the system. This is not the same as modeling the actor (actors are external. by definition) with the same name. w A course registration system maintains information about the Student object which is independent of the fact that the Student also plays a role as an actor of the system. § Completely independent of each other § Student class (entity) will exist whether or not the student is an actor to the system. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 27/29
Review: Generalization (in entity classes) w One class shares the structure and/or behavior of one or more Superclasses (parent) w “Is-a-kind of” relationship w In analysis, use sparingly w Inheritance relationships may Generalization Relationship be identified – especially in entity classes. Account balance name number Withdraw() Create. Statement() Savings Checking In analysis, generalization should be Subclasses used to model shared behavioral Get. Interest() Withdraw() semantics only (that is, generalization Withdraw() that passes “is a kind of’ test) When generalization is found, The use of generalization makes the create a common super-class definition of the abstractions easier to that contains common attributes document and understand. associations, aggregations, and 28/29 operations OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved
Example: Generalization (Shared Semantics)Part-time. Student Full-time. Student Without Generalization name address student. ID grad. Date name address student. ID number. Courses Student With Generalization name address student. ID Parttime. Student Fulltime. Student grad. Date OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved max. Num. Courses 29/29
- Slides: 29