Object Oriented Analysis and Design Using the UML

Objectives: Use-Case Analysis w Understand the purpose of Use-Case Analysis and where in the lifecycle it is performed w Identify the classes which perform a usecase 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 usecase 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

Use Case Analysis w An instance of Use-Case Analysis is performed for each use case to be developed during an iteration. 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. w The allocation of responsibility is modeled in usecase realizations that describe how analysis classes collaborate to perform use cases. w (The use-case realizations will be refined in Use. Case Design. ) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 3

Use-Case Analysis Overview Use Case Analysis is performed By the Designer – once per Iteration per use case realization Software Architecture Glossary Use-Case Document Modeling Guidelines Supplementary Specifications Use-Case Realization (identified) Use-Case Model OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Use-Case Analysis Model (optional) 4 Analysis Classes Use-Case Realization (developed) Design Model

Use Case Analysis - Purpose w To identify the classes which perform a use case’s flow of events w To distribute the use case behavior to those classes w To identify the responsibilities, attributes and associations of the classes w Input Artifacts w Glossary Supplementary Specifications w Use-Case Model Use-Case Flow of Events w Software Architecture Document w Resulting Artifacts w Analysis Classes Analysis Model and/or Design Model w Partially Developed Use-Case Realizations OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 5

Use-Case Analysis Steps – Major ones w Supplement the Use-Case Description § Will probably need some enhancements as we pair down our Use Cases and add alternatives and exceptions. w For each use-case realization, do: § Find classes from Use Case behavior - Study each Use Case flow of events to identify analysis 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 ()…. § Distribute Use-Case Behavior to Classes that you identify § Describe Attributes of each analysis class. § Show associations between the collaborating classes. w Let’s look at each of these in particular…. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 6

Use-Case Analysis Steps w 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 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…. . OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 7

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. 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 • The system retrieves and displays a list of current course offerings from the course catalog legacy database.

Use-Case Analysis Steps w Supplement the Use-Case Description w For each use-case realization § 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) • At this juncture we should have identified a set of candidate analysis classes which will be capable of performing the behaviors described in the use case. • These are now the ‘responsibilities’ of these classes. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 9

Review: Class w Recall, a class is an abstraction w Describes a group of objects with common: § § Properties (attributes) Behavior (operations) Relationships Semantics Class Name Attributes Operations w A class is an abstraction in that it Professor name emp. ID create( ) save( ) delete( ) change( ) § Emphasizes relevant characteristics; suppresses others § Consists of the three sections indicated • First section: Class name • Second section: structure (attributes) • Third section: behavior (operations) w For analysis classes, these entries are sufficient! OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 10

Review: Use-Case Realization Use-Case Model Design Model Use Case Use-Case Realization Sequence Diagrams Collaboration Diagrams Use Case Class Diagrams OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Not what we have so far. 11 These are Design Classes. More

Comments on previous slide w Remember: a use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects. § A use-case realization is one possible realization of a use case. § A use-case realization in the Design Model can be traced to a use case in the Use-Case Model. § A realization relationship is drawn from the use-case realization to the use case it realizes. w A use-case realization can be represented using a set of diagrams (the number and type may vary) w Different organizations may have their own way of doing these things…(and naming them…) OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 12

Continuing Comments… w The diagrams that may be used to realize a use case realization may include: § Interaction Diagrams (sequence and/or collaboration diagrams) can be used to describe how the use case is realized in terms of collaborating objects. • These diagrams model the detailed collaborations of the use-case realization. § Class Diagrams can be used to describe the classes that participate in the realization of the use case, as well as their supporting relationships. • These diagrams model the context of the use-case realization. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 13

Still more Comments… w In our Use Case Analysis step, the usecase realizations' diagrams are outlined. § Exactly what this entails will be discussed ahead and form part of the fourth deliverable. w In subsequent design activities (Use-Case Design) these class diagrams will be considerably refined and updated according to more formal class interface definitions. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 14

w A designer: responsible for the integrity of the use -case realization. w Must coordinate with the designers responsible for the classes and relationships employed in the use -case realization. w The use-case realization can be used by class designers to understand the class’s role in the use case and how the class interacts with other classes. § This implies that a team will/may distribute responsibilities for each class to developers. w This information can be used to determine/refine the class responsibilities and interfaces. w Let’s find the classes from different behaviors the classes must provide… OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 15

Identifying Candidate Classes from Behavior w Will use three perspectives of the system to identify these classes. § 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 perspectives (boundary, control, entity) § These are conveniences used during analysis that will disappear or be transitioned into different design elements during the design process. w Will result in a more robust model because these are three things that are most likely to change in system and so we isolate them so that we can treat them separately. § That is, the interface/boundary, the control, and the key system entities. …. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 16

Find Classes From Use-Case Behavior w The complete behavior of a use case has to be distributed to analysis classes w We must ‘identify’ these classes – identify, name, and briefly describe 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 17

Discovering Classes w Analysis classes represent an early conceptual model for ‘things in the system which have responsibilities and behaviors’. w Analysis classes are used to capture a ‘firstdraft’, rough-cut of the object model of the system. w Analysis classes handle primary functional requirements, interface requirements, and some control - and model these objects from the problem domain perspective. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 18

Kinds of Analysis Classes w Three things likely to change in a system: § The boundary between the system and its actors (interfaces…) § The information a system uses (data), and § The control logic of the system (who does what) w So, we isolate the different kinds of analysis classes § Each of these has a set of canned duties & responsibilities § Again, the distinction between these classes is used in analysis but goes away 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 solutions space. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 19

What is an Analysis Class? Can use with the name of the stereotype In guillemets 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 to a description of how the System will work. System boundary <<control>> Use-case behavior coordination System information OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 20 <<entity>>

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. w Don’t spend a lot of time maintaining this model, as this ‘model’ is largely expendable. w Analysis classes rarely survive into the design unchanged. w Many of them represent whole collaborations of objects, often encapsulated by a single subsystems or a reverse engineered component. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 21

Analysis Classes – Early Conceptual Model w Analysis classes are 'proto-classes', which are essentially "clumps of behavior". w Analysis classes are early conjectures of the composition of the system; they rarely survive intact into implementation. w Many of the analysis classes morph into something else later on (subsystems, components, split classes, combined classes). w They provide us with a way of capturing the required behaviors in a form that we can use to explore the behavior and composition of the system. w Analysis classes allow us to "play" with the distribution of responsibilities, re-allocating, as necessary. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 22

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 23 a structural perspective; static) Exec

What is a Boundary Class? w Insulates the system from changes in the outside w Several Types of Boundary Classes § User interface classes – classes that facilitate communication with human users of the system • Menus, forms, etc. User interface classes…. § System interface classes – classes which facilitate communications with other systems. • These boundary classes are responsible for managing the dialogue with the external system, like getting data from an existing database system or flat file… • Provides an interface to that system for this system § 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>> 24

The Role of a Boundary Class <<boundary>> Actors can only communicate with boundary classe Boundary classes identify the system’s boundaries. <<control>> <<boundary>> Customer External Database? ? <<boundary>> <<entity>> . A boundary class is a class used to model interaction between the system’s surrounding and its inner workings; Involves transforming and translating events and noting change in the system presentation (such as the interface). . Boundary Classes model parts of the system that depend on its surroundings. Entity and control classes model parts that are independent of the 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 25

Boundary Classes - more w Identify boundary classes for things mentioned in the flow of events of the use-case realization. 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? Connection to existing external data…) w One recommendation: for the initial identification of boundary classes is 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 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. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 26

Example: Finding Boundary Classes w One boundary class per actor/use case pair: Student Register for Courses Course Catalog System <<boundary>> Register. For. Courses. Form <<boundary>> Course. Catalog. System • The Register. For. Courses. Form contains a Student's "schedule-in-progress". It displays a list of Course Offerings for the current semester from which the Student may select to be added to his/her Schedule. • The Course. Catalog. System interfaces with the legacy system that provides the unabridged catalog of all courses offered by the university. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 27

Guidelines: Boundary Class – User Interface classes w 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 much more detail later) § 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. ) § The expansion, refinement and replacement of these boundary classes with actual user interface classes is a very important activity of Class Design – later § 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. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 28

Guidelines: Boundary Classes – System and Device w System and Device Interface Classes § Concentrate on what protocols must be defined • Note that your application must interface with an existing ‘information source. ’ § Do NOT concentrate on how the protocols will be implemented 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. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 29

What is an Entity Class? (recall: boundary, entity, control…) w Key abstractions of the system Analysis class stereotype <<entity>> Glossary Sources for entity Classes: Glossary Use-Case Flow of Use Case Events Business domain model Business-Domain Model 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 30

Entity Classes w Entity classes represent stores of information in the system w They are typically used to represent the key concepts the system manages. w 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, …) w They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system. w The main responsibilities of entity classes are to store and manage information in the system. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 31

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; sometime, an entity object is not even specific to the system itself. <<entity>> Store and manage information in the system The values of its attributes and 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 32

Example: Finding Entity Classes w Use use-case flow of events as input w Key abstractions of the use case w Traditional, filtering nouns approach § 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) § Remove operations OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 33

Example: Candidate Entity Classes w Register for Courses (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 OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 34

Candidate Entity Classes - continued w 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). These classes are sometimes called “surrogates”. w 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. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 35

Review: Generalization 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 Generalization w Inheritance relationships may be Relationship 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. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved Account balance name number Withdraw() Create. Statement() Checking Savings Withdraw() Get. Interest() Withdraw() Subclasses When generalization found, create a common super-class that contains common attributes associations, aggregations, and 36 operations

Finding Generalization: Generalization of Classes Savings Stock Checking More general Real. Estate Bond Asset Base class subclasses Bank. Account Security Real. Estate Subclasses have Unique semantics And behavior. Savings Checking Stock Bond Can generalize when you have a set of classes that share some semantics and behavior OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 37

Finding Generalization: Specialization of Classes Asset Bank. Account Savings Checking Security Stock Real. Estate Bond More specific More specialized properties are placed in the lower part of the inheritance hierarchy. OOAD Using the UML - Use-Case Analysis, v 4. 2 Copyright Ó 1998 -1999 Rational Software, all rights reserved 38

Example: Generalization (Shared Semantics) Without Generalization Part-time. Student Full-time. Student name address student. ID number. Courses name address student. ID grad. Date 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 39