Chapter 5: Analysis Object Modeling.

Slides:



Advertisements
Similar presentations
From use cases to classes (in UML). A use case for writing use cases Use case: writing a use case Actors: analyst, client(s) Client identifies and write.
Advertisements

Page 1W5D1 Models. Help us: Understand the system Verify the system Communicate with / coordinate development teams.
Requirements Elicitation Labs Discussion p2 T120B pavasario sem.
Presentation material is based on notes from Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 ECE.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation.
Winter 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Assignment 2 due today. Assignment 3 is a GUI – posted soon. Due the end of next week. Project work.
Using UML, Patterns, and Java Object-Oriented Software Engineering Requirements Analysis (Part 1 – Object Modeling)
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5: Analysis, Object Modeling.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Analysis: Dynamic Modeling.
Slide 1 Chapter 7 Structural Modeling. Slide 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business.
Requirements Elicitation Chapter 4. Establishing Requirements Two questions –What is the purpose of the system –What is inside and what is outside the.
Use Cases Chapter 4. After Scenarios Find all the use cases in the scenario that specifies all possible instances of how to report a fire –Ex: “Report.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Object Modeling.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
INTROSE Introduction to Software Engineering Raymund Sison, PhD College of Computer Studies De La Salle University Analysis Modeling.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Functional Modeling.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
Requirements Analysis
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 5, Analysis: Object Modeling.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Course slides Slightly modified from Uğur Doğrusöz’s.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5, Object Modeling.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
UNB CS3013 Software Engineering II lectures adapted from Bernd Bruegge & Allen Dutoit, Object-Oriented Software Engineering: Conquering Complex and Changing.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 1 Object Modeling.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 5: Analysis, Object Modeling.
Slide 1 Structural Modeling Chapter 7. Slide 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 4, Requirements Elicitation: Functional Modeling.
Design Model Lecture p6 T120B pavasario sem.
1 Object Oriented Analysis Lectures 12 & References Chapter 4: Requirements Elicitation from Object Oriented Software Engineering: Conquering Complex.
OMT Modeling 1. Object Model : presented by the object model and the data dictionary. 2. Dynamic Model: presented by the state diagrams and event flow.
Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Project Wikis are private again. Assignment 3 is posted. Due Nov. 6. SDD framework must be in place.
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 5, Analysis: Object Modeling.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Elaboration popo.
Chapter 5, Object Modeling
Systems Analysis and Design in a Changing World, Fourth Edition
CHAPTER
An Overview of Requirements Engineering Tools and Methodologies*
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Requirements Engineering Process
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 5: Analysis Object Modeling.
Unified Modeling Language
Chapter 5: Analysis, Object Modeling
OO Domain Modeling With UML Class Diagrams and CRC Cards
Abstract descriptions of systems whose requirements are being analysed
Chapter 4, Requirements Elicitation: Functional Modeling
OO Domain Modeling With UML Class Diagrams and CRC Cards
Object-Oriented Analysis
University of Houston-Clear Lake
Chapter 4, Requirements Elicitation: Functional Modeling
Analysis models and design models
Software Design Lecture : 15.
CISC/CMPE320 - Prof. McLeod
Copyright 2007 Oxford Consulting, Ltd
Chapter 4, Requirements Elicitation: Functional Modeling
Chapter 5, Analysis: Object Modeling
Design Yaodong Bi.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Chapter 4 System Modeling.
Presentation transcript:

Chapter 5: Analysis Object Modeling

A Projector System Use Case Objects Sequence Diagram …. Show Slides User, Laptop, and Screen are actors Objects controlPad, Lens, PresentationControl, Sequence Diagram ….

Outline Analysis model overview Activities during object modeling Object identification Object types entity, boundary and control objects Object naming Abbott’s technique helps in object identification Users of class diagrams

Analysis Model Overview Use case diagram Class diagram Statechart diagram Sequence diagram functional model object model dynamic model analysis model

Analysis Model vs. Design Model Analysis model: Application domain model System Design and Object design models: Solution domain model They all use class diagram, dequence diagram, and state chart diagram, but focus on different aspects

Activities during Object Modeling Main goal: Find the important abstractions (classes) Steps during object modeling 1. Class identification 2. Find the attributes 3. Find the methods 4. Find the associations between classes Order of steps Goal: get the desired abstractions Order of steps secondary, only a heuristic Iteration is important Start with review: What is a model? What is an abstraction? They are used synonomously and mean they provide a simplified view of a complex system that we cannot understand by looking at all of its components simultaneously. Models by their definition abstract away important characteristics of a system by emphasizing other aspects. Example: Clay model concentrates on the form of the car, nobody can sit in it. Prototypes are models. Iterate and correct the model: A scientific model is always like a hypothesis. The important part of a scientific model is that it is falsifiable. This is an important aspect of prototyping. They are immediately understandable and can be falsified (that is our theory of how the application should work!). This is one of the main strengths of prototyping: End user falsifiability. Redesign (Falsification principle in science: Work with model until it is proven to be false)

Class identification The application domain has to be analyzed. Depending on the purpose of the system different objects might be found How can we identify the purpose of a system? Scenarios and use cases Another important problem: Define system boundary. What object is inside, what object is outside?

What is This? Face Question: What is the drawing showin in this slide? Students in general answer first: Two faces, a happy and a serious one. Or a serious and a sad one. Point out that there are no two objects: If you decide on a serious face, cover the serious face and show what is left over. It is clear now, that the remains are not a complete face, because one eye is overused (resource contention!) and the object modeler has to decide whether it is part of the serious or the sad face. The drawing in this slide is an example of an incomplete object model. What does this translates to into the real object modeling activity? It means we have discovered an incomplete object model and must ask the client to provide us with more information to fill out the missing information or to define the objects for us (after all we might be looking at siamese twins!). 1..2 Eye

Modeling in Action Face Mask Sad Happy  Mood Is it one Face or two? Who is using it? Person at Carnival? Bankrobber? Painting collector How is it used? Wear on? Clean?

Pieces of an Object Model Classes Associations (Relations) Generic associations Canonical associations Part of- Hierarchy (Aggregation) Kind of-Hierarchy (Generalization) Attributes Detection of attributes Application specific Attributes in one system can be classes in another system Turning attributes to classes Operations Detection of operations Generic operations: Get/Set, General world knowledge, design patterns Domain operations: Dynamic model, Functional model

Object vs Class Object (instance): Exactly one thing This lecture on Software Engineering on November 15 from 14:30 -16:00 A class describes a group of objects with similar properties Game, Tournament, mechanic, car, database Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): Class diagram: Template for describing many instances of data. Useful for taxonomies, patterns, schemata... Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples

How do you find classes? Finding objects is the central piece in object modeling Learn about problem domain: Observe your client Apply general world knowledge and intuition Take the flow of events and find participating objects in use cases Try to establish a taxonomy Do a syntactic analysis of problem statement, scenario or flow of events Abbott Textual Analysis, 1983, also called noun-verb analysis Nouns are good candidates for classes Verbs are good candidates for opeations Apply design knowledge: Distinguish different types of objects Apply design patterns (Lecture on design patterns) Q: What key ideas have we covered so far? A: Patterns, analysis documentation standard, inheritance and multiple inheritance. In the last part of this lecture I would like to come back to the problem of object identification and another tool that helps you infinding objects. Patterns: A way to put your knowledge about object modeling into drawers. Analysis documentation standard: The “official” way of drawing object models. The major elements are: CASE Tool Entry: Executive summary and one subsystem per sheet. 7+-2 classes per sheet. Documentation: Each subsystem has navigational text. Difference between aggregation and inheritence Object identification: Using textual analysis Multiple Inheritance: Why it cannot be avoided, how you can deal with it. Software engineering as a special case of Epistemology: Software engineering is a join class of materialism (budget and deadline influencing your modeling (They might limit what you can achieve!). Idealism: Some of the classes do not reflect reality (that is, the customer does not know about them) and dialecticism (iteration and incremental analysis with user participatory decision making capabilities).

Object Types Entity Objects Boundary Objects Control Objects: Represent the persistent information tracked by the system (Application domain objects, “Business objects”) Boundary Objects Represent the interaction between the user and the system Control Objects: Represent the control tasks performed by the system Having three types of objects leads to models that are more resilient to change. The interface of a system changes more likely than the control The control of the system change more likely than the application domain Object types originated in Smalltalk: Model, View, Controller (MVC)

Example: 2BWatch Objects Button Year ChangeDate Month LCDDisplay Day Entity Objects Control Objects Interface Objects

Naming of Object Types in UML UML provides several mechanisms to extend the language UML provides the stereotype mechanism to present new modeling elements <<Boundary>> Button <<Entity>> Year <<Control>> ChangeDate <<Entity>> Month <<Boundary>> LCDDisplay <<Entity>> Day Entity Objects Control Objects Boundary Objects

Recommended Naming Convention for Object Types To distinguish the different object types on a syntactical basis, we recommend suffixes: Objects ending with the “_Boundary” suffix are boundary objects Objects ending with the “_Control” suffix are control objects Entity objects do not have any suffix appended to their name. Button_Boundary Year ChangeDate_ Control Month LCDDisplay_Boundary Day Back to the example of classroom multimedia system

Let’s do Object Modeling – P181 Use Case name: ReportEmergency Flow of events The FieldOfficer activates the “Report Emergency” function of her terminal. FRIEND responds by presenting a form to the officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource request, and hazardous material fields. The FieldOfficer fills the form, by specifying minimally the emergency type and description fields. The FieldOfficer may also describes possible responses to the emergency situation and request specific resources. Once the form is completed, the FieldOfficer submits the form by pressing the “Send Report” button, at which point, the Dispatcher is notified. The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All the information contained in the FieldOfficer’s form is automatically included in the incident. The Dispatcher selects a response by allocating resources to the incident (with the AllocateResources use case) and acknowledges the emergency report by sending a FRIENDgram to the Fieldofficer. The FieldOfficer receives the acknowledgment and the selected response.

Exercise Define at least 3 entity objects, 4 boundary objects, and 2 control objects

Heuristics for Identifying Entity Objects Pick a use case and look at its flow of events Find terms that developers or users need to clarify in order to understand the flow of events Look for recurring nouns (e.g., Incident), Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource), Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan), Identify data sources or sinks (e.g., Printer) Identify interface artifacts (e.g., PoliceStation) Be prepared that some objects are still missing and need to be found: Model the flow of events with a sequence diagram Always use the user’s terms

Object Dictionary Dispatcher Police officer who manages Incidents. A Dispatcher opens, documents, and closes Incidents in response to Emergency Report and other communication with FieldOfficers. Dispatchers are identified by badge numbers. EmergencyReport Initial report about an Incient from a FieldOfficer to a Dispatcher. An EmergencyReport usually triggers the creation of an Incident by the Dispatcher. An EmergencyReport is composed of an emergency level, a type, a location, and a description. Incident Siutation requiring attention from a fieldOfficer. An Incient may be reported in the system by a FieldOfficer or anybody else external to the system. An Incient is composed of a description, a response, a status, a location, and a number of FieldOffier.

Heuristics for Identifying Boundary Objects Identify user interface controls that the user needs to initiate the use case (e.g., ReportEmergencyButton) Identify forms the user needs to enter data into the system (e.g., EmergencyReportForm) Identify notices and messages the system uses to respond to the user (e.g., AcknowledgmentNotice) When multiple actors are involved in a use case, identify actor terminals (e.g., DispatcherStation) to refer to the user interface under consideration.

Heuristics for Identifying Control Objects Identify one control object per use case Identify one control object per actor in the user case. The life span of a control object should cover the extend of the use case or extend of a user session. If it is difficult to identify the beginning and the end of a control object activation, the corresponding use case probably does not have well-defined entry and exit conditions.

Let’s do Object Modeling – P181 Entity – yellow Boundary – blue Control -- red Use Case name: ReportEmergency 1. The FieldOfficer activates the “Report Emergency” button of her terminal. FRIEND responds by presenting a form to the officer. The form includes an emergency type menu (general emergency, fire, transportation), a location, incident description, resource request, and hazardous material fields. The FieldOfficer fills the form, by specifying minimally the emergency type and description fields. The FieldOfficer may also describes possible responses to the emergency situation and request specific resources. Once the form is completed, the FieldOfficer submits the form by pressing the “Send Report” button, at which point, the Dispatcher is notified. The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. All the information contained in the FieldOfficer’s form is automatically included in the incident. The Dispatcher selects a response by allocating resources to the incident (with the AllocateResources use case) and acknowledges the emergency report by sending a FRIENDgram to the Fieldofficer. The FieldOfficer receives the acknowledgment and the selected response.

Let’s do Object Modeling – P181 Entity Objects: Dispatcher, EmergencyReport, FieldOfficer, Incident Boundary Objects: AcaknowledgmentNotice, DispatcherStation, ReportEmergencyButton, EmergencyReportForm, FieldOfficerStation, IncidentForm Control Objects: ReportEmergencyControl (on the FieldOfficerStation side), ManageEmergencyControl (on the DispatcherStation side)

Abbott Textual Analysis Nouns are good candidates for classes Verbs are good candidates for operations Good for generating a list of initial candidate objects Advantage: focusing on the user’s terms Limitations: The quality of object model depends highly on the style of writing There are many more nouns than relevant classes

Example: Flow of events The customer enters a store with the intention of buying a toy for his child with the age of 7. Help must be available within less than one minute. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. The customer selects a dangerous toy which is kind of unsuitable for the child. The store owner recommends a more yellow doll.

Mapping parts of speech to object model components [Abbott, 1983] Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

customer leaving the store Another Example Flow of events: The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. Is this a good use Case? An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely the boardgame “Monopoly". Not quite! The use case should terminate with the customer leaving the store

Textual Analysis using Abbot‘s technique Grammatical construct Example UML Component “Monopoly" Concrete Person, Thing Object “toy" noun class "3 years old" Adjective Attribute “enters" verb Operation “depends on…." Intransitive verb Operation (Event) “is a" ,“either..or", “kind of…" Classifying verb Inheritance "Has a ", “consists of" Possessive Verb Aggregation “must be", “less than…" modal Verb Constraint

Generation of a class diagram from flow of events Customer The customer enters the store to buy a toy. It has to be a toy that his daughter likes and it must cost less than 50 Euro. He tries a videogame, which uses a data glove and a head-mounted display. He likes it. customer enters store buy toy daughter store enter() ? enter() less than 50 Euro videogame daughter daughter age suitable * An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely a boardgame. The customer buy the game and leaves the store depends toy price buy() like() toy toy buy() age type of toy boardgame videogame boardgame

Order of activities in modeling Formulate a few scenarios with help from the end user and/or application domain expert. Extract the use cases from the scenarios, with the help of application domain expert. Analyse the flow of events, for example with Abbot's textual analysis. Generate the class diagrams, which includes the following steps: Class identification (textual analysis, domain experts). Identification of attributes and operations (sometimes before the classes are found!) Identification of associations between classes Identification of multiplicities Identification of roles Identification of constraints

Some issues in object modeling Improving the readability of class diagrams Managing object modeling Different users of class diagrams

Avoid Mixing All Models Together Customer Name CustomerId Account Amount Deposit() Withdraw() GetBalance() AccountId Bank Has * Savings Account Checking Account Mortgage Account Don’t put too many classes into the same package: 7+-2 (or even 5+-2) Withdraw() Withdraw() Withdraw()

Put Taxonomies on a separate Diagram Account Amount Deposit() Withdraw() GetBalance() CustomerId AccountId Savings Account Checking Account Mortgage Account Withdraw() Withdraw() Withdraw()

Project Management Heuristics Explicitly schedule meetings for object identification First just find objects Then try to differentiate them between entity, interface and control objects Find associations and their multiplicity Unusual multiplicities usually lead to new objects or categories Identify Inheritance: Look for a Taxonomy, Categorize Identify Aggregation Allow time for brainstorming , Iterate, iterate

Who uses class diagrams? Purpose of Class diagrams : The description of the static properties of a system (main purpose) Who uses class diagrams? The customer and the end user are often not interested in class diagrams. They usually focus more on the functionality of the system. The application domain expert uses class diagrams to model the application domain The developer uses class diagrams during the development of a system,that is, during analysis, system design, object design and implementation.

Class-diagrams have different types of „users“ According to the development activity, the developer plays different roles. Analyst System-Designer, DetailedDesigner Implementor. In small systems some of the roles do not exist or are played by the same person. Each of these roles has a different view about the models. Distinguish the types of classes that appear in class diagrams. Application domain classes Solution domain classes

Application domain vs solution domain The problem domain (financial services, meteorology, accident management, architecture, …). Application domain class: An abstraction in the application domain. If we model business applications, these classes are also called business objects. Example: Board game, Tournament Solution domain: Domains that help in the solution of problems (tele communication, data bases, compiler construction, operting systems, ….) Solution domain class: An abstraction, that is introduced for technical reasons, because it helps in the solution of a problem. Examples: Tree, Hashtable, Scheduler

The Role of the Analyst The analyst is interested in application classes: The associations between classes are relationships between abstractions in the application domain. whether the use of inheritance in the model reflect the taxonomies in the application domain. Definition Taxonomy: A hierarchy of abstractions The analyst is not interested in the exact signature of operations. in solution classes.

Designer The designer focuses on the solution of the problem, that is the solution domain. Design consists of many tasks (subsystem decomposition, selection of the hardware platform, data management system, etc.). An important design problem is the specification of interfaces: The designer describes the interface of classes (object design) and subsystems (system design). The goal of the designer is usability and reusability of interface Design-Usability: the interfaces are usable from as many classes as possible within in the system. Design-Reusability: Definition of interfaces, such that they can also be used in other (future) software systems. => Class libraries.

Why do we distinguish these different users of class diagrams? Models often don‘t distinguish between application classes (“address book") and solution class (“array", “tree"). Reason: Modelling languages like UML allow the use of both types of classes in the same model. Preferred : No solution classes in the analysis model. Many systems don‘t distinguish between specification and implementation of a class. Reason: Object-oriented programming languages allow the simultaneous use of specification and implementation of a class. Preferred: The object design model does not contain implementations. The key for creating high quality software systems is the exact distinction between Application and solution domain classes Interface specification and implementation specification

Summary System modeling Object modeling is the central activity Dynamic model Functional model Object modeling is the central activity Class identification is a major activity of object modeling There are some easy syntactic rules to find classes/objects Different roles during software development Requirements Analysis Document Structure