1 / 34

Object Oriented Analysis and Design Using the UML

Object Oriented Analysis and Design Using the UML. Use Case Analysis Modified considerably by your Instructor. Objectives: Use-Case Analysis. Understand the purpose of Use-Case Analysis and where in the lifecycle it is performed

elsiecook
Télécharger la présentation

Object Oriented Analysis and Design Using the UML

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Object Oriented Analysis and Design Using the UML Use Case Analysis Modified considerably by your Instructor

  2. Objectives: Use-Case Analysis • Understand the purpose of Use-Case Analysis and where in the lifecycle it is performed • Identify the classes needed to accommodate a use- case flow of events (Analysis Classes) • Distribute the use-case behavior to those classes, identifying responsibilities of the classes • The analysis classes and the initial use-case realizations are the key model elements that we develop in this activity.

  3. Use Case Analysis • The focus during Use-Case Analysis is on a particular use case. • 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.) • The allocation of responsibility is modeled in use-case realizations that describe how analysis classes collaborate to perform (realize) use cases.

  4. Software Architecture Document – (don’t really have this one yet.) Analysis Classes Design Model Use-Case Modeling Guidelines Supplementary Specifications Glossary Use-Case Model Analysis Model (optional) Use-Case Realization (identified) Use-Case Realization (developed) Use-Case Analysis Overview Use Case Analysis is performed By the Designer – once per Iteration per use case realization Use-Case Analysis

  5. Use Case Analysis - Purpose • To identify analysis classes which perform a use case’s flow of events • To distribute the use case behavior to those classes • To identify the responsibilities, attributes and associations of the classes • Input Artifacts – see previous slide • Output Artifacts • Analysis Classes • Analysis Model • Partially Developed Use-Case Realizations • Work toward Design Model (first cut, really)

  6. Use-Case Analysis Steps – Major ones • 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… • 2. For each use-case realization, do: • Study Use Case flow of events - identify analysis classes from the Use Case narrative. Identify interface, control, and data classes. • Allocatebehaviors (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 ()…. • Distribute Use-Case Behavior to Classes that you identify • DescribeAttributes (properties) of each analysis class. • Showassociations between the collaborating classes. • Let’s look at each of these two major items in particular….

  7. Use-Case Analysis Steps • 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… • This is why we spend so much time on getting those use cases right – recall, Use Cases drive the whole shooting match! • Update flows of events as needed….. • You will likely collapse some use cases and identify others missed. • But this is difficult to do. Consider 

  8.  Supplement the Use-Case Description  Sometimes the description of the use case is not sufficient for identifying analysis classes and their objects. Remember, customer 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. To find objects that perform the use cases, we may need ‘white box’ descriptions – that is, what does the system do from an internal perspective. From this, some objects may be identified. Many times we do not have enough detail. • The system retrieves and displays a list of current course offerings from the course catalog legacy database • given specific • parameters, such as... • The system displays a list of course offerings.

  9. Use-Case Analysis Steps • Supplement the Use-Case Description • 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) • We should be able to identify a set of candidate analysis classes capable of performing the behaviors (actions; ‘verbs’) described in the use case. • These are now the ‘responsibilities’ of these classes.

  10.  Find Candidate Classes from Behavior (1 of 2) • Will use three ‘division of responsibilities’ of the system to identify these classes. • Look for Classes that form: • The ‘boundary’ between the system and its actors • The ‘information’ the system uses • The ‘control logic’ of the system

  11.  Find Candidate Classes from Behavior (2 of 2) • 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.) •  This approach results in a more robust model because these are the three things that are most likely to change in system and so we isolate them so that we can treat them separately.

  12. <<boundary>> <<boundary>> <<control>> <<entity>> <<entity>> Find Classes From Use-Case Behavior • The complete behavior of a use case must be distributed to analysis classes • We must ‘identify’ these classes – give a name and briefly describe what they do in a few sentences.

  13. Kinds of Analysis Classes • As mentioned, three things likely to change in a system: • The boundary between the system and its actors (interfaces… to end-users, external systems, devices…) • The information a system uses (data), and • The controllogic of the system (who does what) • So, we isolate the different kinds of concerns and use analysis classes to capture these responsibilities. • Each category of analysis class has a typical set of duties & responsibilities • (Again, the distinction between classes used in analysis change in design or becomes less of an issue as we transition these analysis classes into design artifacts / design entities to accommodate the problem domain representations in a solution space.)

  14. <<boundary>> <<control>> <<entity>> What is an Analysis Class? Can use with the name of the stereotype In angle brackets or as symbols with unique icons.  Finding a candidate set of classes is the first part of transforming a mere statement of required behavior to a description of how the System will work. So, we start with Analysis Classes. Use-case behavior coordination System boundary System information

  15. Analysis Classes – an Early Conceptual Model • The analysis classes, taken together, represent an early conceptual model of the system. • This conceptual model evolves quickly and remains fluid for some time as different representations and their implications are explored. • Don’t spend a lot of time maintaining this model, as this ‘model’ is largely expendable. • Analysis classes rarely survive into the design unchanged. •  Many of them represent whole collaborations of objects, often encapsulated by a single subsystems or a reverse engineered component.

  16. Analysis Classes – Early Conceptual Model • Many of the analysis classes morph into something else later on (subsystems, components, split classes, combined classes). • They provide us with a way of capturing the requiredbehaviors in a form that we can use to explore the behavior and composition of the system. • Analysis classes allow us to "play" with the distribution of responsibilities, re-allocating, as necessary.

  17. Analysis Classes: A First Step Towards Executables Use Cases AnalysisClasses DesignElements Source Code Exec Use-Case Analysis (…from a structural perspective; static)

  18. <<boundary>> What is a Boundary Class? • Insulates the system from changes in the outside • Several Types of Boundary Classes • 1. User interface classes – classes that facilitate communication with human users of the system • Menus, forms, 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

  19. <<control>> <<boundary>> <<boundary>> <<boundary>> Customer <<entity>> <<entity>> The Role of a Boundary Class • Actors can only communicate with boundary classes. • Boundary classes identify the system’s boundaries. External Database << boundary>> • A boundary class is used to model interaction between the 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.

  20. Boundary Classes - more •  Identify boundary classes for actor interactions mentioned in the flow of events of the use-case •  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, etc. •  Heuristic: initial identification of boundary classes: one boundary class per actor/use-case pair. • This class can be viewed as having responsibility for coordinating the interaction with the actor. • This may be (likely will be) refined as a more detailed analysis is performed. • This is particularly true for window-based GUI applications, where there is typically one boundary class for each window, or one for each dialog.

  21. Student Register for Courses Course Catalog System <<boundary>> RegisterForCoursesForm <<boundary>> CourseCatalogSystem Example: Finding Boundary Classes • One boundary class per actor/use case pair: Two boundary classes: • The RegisterForCoursesForm 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. • The CourseCatalogSystem interfaces with the legacy system that provides the • unabridged catalog of all courses offered by the university.

  22. Guidelines: Boundary Class – User Interface classes • 1. User Interface Classes • Concentrate on what information is presented to the user • Do NOT concentrate on the UI details • 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.)

  23. Guidelines: Boundary Class – User Interface classes • The expansion, refinement and replacement of these boundary classes with actual user interface classes is a very important activity of Class Design – later • We merely want to establish them here. • 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 – not every button, list, etc. in the GUI.

  24. Guidelines: Boundary Classes – System and Device • 2-3. System and Device Interface Classes • Concentrate on whatprotocols 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. • If the interface to an existing systemor device is already well-defined, the boundary class responsibilities should be derived directly from the interface definition. • If there is a working communication with the external system or device, make note of it for later reference during design.

  25. <<entity>> Business-Domain Model Glossary Architectural Analysis Abstractions What is an Entity Class? (recall: boundary, entity, control…) • Key abstractions of the system Analysis class stereotype Sources for entity Classes: Glossary Use-Case Flow of Events Domain Model Entity classes show the logical data structure, which will help us understand what the system is supposed to offer to its users. Use Case things…… Environment Independent

  26. Entity Classes • Entity classes represent stores of information in the system • Used to represent the key concepts the system manages. (Core Abstractions) • Entity objects (instances of entity classes) are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. • (Chapter advisor, memorabilia, university, student, correspondence_item, International_Secretary, Provider, Worker…)

  27. Entity Classes - more • They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system. • Many of these will come from the Domain Model, and your creation of entity classes may result in refinements to the domain model, as you discover that you ‘come up short’ of needed entity classes in your modeling… • The main responsibilities of entity classes are to store and manage information in the system.

  28. <<boundary>> <<control>> <<boundary>> Customer <<boundary>> <<entity>> <<entity>> The Role of an Entity Class Entity objects can have complicated behavior; however, unlike other objects, this behavior is strongly related to the phenomenon the entity object represents. Entity objects are usually not specific to one use-case realization; sometime, an entity object is not even specific to the system itself. The values of an entity object and their relationships are often given by an actor. Entity objects are independent of the environment (actors) Store and manage information in the system

  29. Example: Finding Entity Classes • Use use-case flow of events and domain model and glossary as inputs. • The more of these you have the better you are! • Traditional, filteringnouns approach (but I’d recommend using classes from the domain model as a starting place, if available) • Underline noun clauses in the use-case flow of events • Remove redundant candidates • 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. • Remove operations

  30. CourseOffering Schedule Student Example: Candidate Entity Classes • Register for Courses (Create Schedule) A person enrolled in classes at the university A specific offering for a course including days of week and times The courses a student has selected for current semester

  31. Candidate Entity Classes - continued • Sometimes there is a need to model information about an actor within the system. This is not the same as modeling the actor (actors are external. by definition). • For example, a course registration system maintains information about the Student which is independent of the fact that the Student also plays a role as an Actor of the system. • This information about the student that is stored in a ‘Student’ class is completely independent of the ‘actor’ role the student plays; • The Student class (entity) will exist whether or not the student is an actor to the system.

  32. Account balance Superclass (parent) name number Withdraw() CreateStatement() Generalization Relationship Savings Checking Subclasses GetInterest() Withdraw() Withdraw() Review: Generalization (in entity classes) • One class shares the structure and/or behavior of one or more classes • “Is-a-kind of” relationship • In analysis, use sparingly • Inheritance relationships may be identified – especially in entity classes. In analysis, generalization should be used to model shared behavioral semantics only (that is, generalization that passes “is a kind of’ test) The use of generalization makes the definition of the abstractions easier to document and understand. When generalization is found, create a commonsuper-class that contains common attributes associations, aggregations, and operations

  33. Savings Checking Stock Bond More general RealEstate Asset BankAccount Security RealEstate Savings Checking Stock Bond Finding Generalization: Generalization of Classes Base class Subclasses Subclasses have Unique semantics And behavior. Can generalize when you have a set of classes that share some semantics and behavior

  34. Example: Generalization (Shared Semantics) Full-timeStudent Part-timeStudent name WithoutGeneralization name address address studentID studentID numberCourses gradDate Student name WithGeneralization address studentID ParttimeStudent FulltimeStudent maxNumCourses gradDate

More Related