Chapter5Analysis,ObjectModeling

Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java,29,Using UML, Patterns, and Java,Object-Oriented Software Engineering,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,Chapter 5: Analysis,Object Modeling,An overview of OOSE development activities and their products,Problem Statement,Requirements Elicitation,Functional Model,Non-functional Req.,Analysis,Analysis Object Model,Dynamic Model,Use Case Diagrams,System Design,State Diagrams,Sequence Diagrams,Class Diagrams,Activity Diagrams,Activities during Object Modeling,Main goal: Find important abstractions,Steps during object modeling,1. Class identification,Based on fundamental assumption that we can find abstractions,2. Find attributes,3. Find methods,4. Find associations between classes,Order of steps,Goal: get desired abstractions,Order of steps secondary, only a heuristic,What happens if we find wrong abstractions?,We iterate and revise the model,Class Identification,Class identification is crucial to OO modeling,Helps to identify important entities of a system,Basic assumptions:,1. We can find classes for a new software system,(Forward Engineering),2. We can identify classes in an existing system,(Reverse Engineering),Why can we do this?,Philosophy, science, experimental evidence,Class Identification,Approaches,Application domain approach,Ask domain experts to identify relevant abstractions,Syntactic approach,Start with use cases,Analyze text to identify objects,Extract participating objects from flow of events,Design patterns approach,Use reusable design patterns,Component-based approach,Identify existing solution classes,Class Identification is a Hard Problem,One problem: Definition of system boundary:,Which abstractions are outside, which abstractions are inside the system boundary?,Actors are outside the system,Classes/Objects are inside the system.,Another problem: Classes/Objects are not just found by taking a picture of a scene or domain,Application domain has to be analyzed,Depending on purpose of system, different objects might be found,How can we identify purpose of a system?,Scenarios and use cases = Functional model,There are different types of Objects,Entity Objects,Represent persistent information tracked by the system (Application domain objects, also called “Business objects”),Boundary Objects,Represent interaction between user and the system,Control Objects,Represent the control tasks performed by the system,Example: 2BWatch Modeling,Year,Month,Day,ChangeDate,Button,LCDDisplay,Entity Objects,Control Object,Boundary Objects,To distinguish different object types,in a model we can use the,UML Stereotype mechanism,Naming Object Types in UML,UML provides,stereotype,mechanism to introduce,new types,of modeling elements,Drawn as a name enclosed by angled double-quotes () and placed before name of a UML element (class, method, attribute, ),Notation: Name,Year,ChangeDate,Button,Month,Day,LCDDisplay,UML is an Extensible Language,Stereotypes allow you to extend vocabulary of UML so that you can create new model elements, derived from existing ones.,Examples:,Stereotypes can also be used to classify method behavior such as, or ,To indicate the interface of a subsystem or system, one can use the stereotype (Lecture System Design),Stereotypes can be represented with icons and graphics:,This can increase readability of UML diagrams.,Object Types allow us to deal with Change,Having three types of objects leads to models that are more resilient to change,Interface of a system changes more likely than control,The way the system is controlled changes more likely than entities in application domain,Object types originated in Smalltalk:,Model, View, Controller (MVC),Model Entity Object,View Boundary Object,Controller Control Object,Finding Participating Objects in Use Cases,Pick a use case and look at flow of events,Do a textual analysis (noun-verb analysis),Nouns are candidates for objects/classes,Verbs are candidates for operations,This is also called,Abbotts Technique,After objects/classes are found, identify their types,Identify,real world entities,that the system needs to keep track of (FieldOfficer,Entity Object),Identify,real world procedures,that the system needs to keep track of (EmergencyPlan,Control Object),Identify,interface artifacts,(PoliceStation,Boundary Object).,Mapping parts of speech to model components (Abbots Technique),Part of speech,Proper noun,Improper noun,Doing verb,being verb,having verb,modal verb,adjective,transitive verb,intransitive verb,UML model component,object,class,operation,inheritance,aggregation,constraint,attribute,operation,constraint, class,association,Example,“Monopoly”,Toy,Buy, recommend,is-a,has an,must be,dangerous,enter,depends on,VideoGame,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.,Generating a Class Diagram from Flow of Events,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,customer enters,depends,store,Customer,?,enter(),Toy,Daughter,suitable,*,Store,enter(),Toy,buy(),toy,age,videogame,daughter,boardgame,Flow of events:,Toy,price,buy(),like(),buy,type of toy,BoardGame,Daughter,age,50 Euro,Other Ways to find Objects,Use other knowledge sources:,Application knowledge:,End users and experts know abstractions of application domain,Solution knowledge:,Abstractions in solution domain,General world knowledge:,Your generic knowledge and intuition,Order of Activities for Object Identification,Formulate a few scenarios with help from an end user or application domain expert,Extract use cases from scenarios, with help of an application domain expert,3. Then proceed in parallel with following:,Analyze flow of events in each use case using Abbots textual analysis technique,Generate UML class diagram,Steps in Generating Class Diagrams,Class identification (textual analysis, domain expert),Identification of attributes and operations (sometimes before classes are found!),Identification of relations:,Associations between classes,Multiplicities,Roles,Inheritance,Who uses Class Diagrams?,Purpose of class diagrams,Description of static properties of a system,Main users of class diagrams:,Application domain expert,uses class diagrams to model application domain (including taxonomies),during requirements elicitation and analysis,Developer,uses class diagrams during development of a system,during analysis, system design, object design and implementation,Who does not use Class Diagrams?,The,client,and the,end user,are usually not interested in class diagrams,Clients focus more on project management issues,End users are more interested in functionality of the system.,Developers have different Views on Class Diagrams,According to the development activity, a developer plays different roles:,Analyst,System Designer,Object Designer,Implementor,Each of these roles has a different view about class diagrams (object model).,The View of the Analyst,The analyst is interested,in,application classes,:,associations between classes are relationships between abstractions in application domain,operations and attributes of application classes,The analyst uses inheritance in the model to reflect taxonomies in application domain,Taxonomy:,An is-a-hierarchy of abstractions in an application domain,The analyst is,not,interested,In exact signature of operations,in solution domain classes,The View of the Designer,The designer focuses on solution of problem (i.e.,solution domain,),Associations between classes are now,references,(pointers) between classes in solution domain,The designer describes,interface,of subsystems (system design) and classes (object design),Goals of the Designer,Design usability,:,interfaces are usable from as many classes as possible within the system,Design reusability,:,interfaces are designed in a way that they can also be reused by other (future) software systems,= Class libraries,= Frameworks,= Design patterns,The View of the Implementor,Class implementor,Must realize interface of a class in a programming language,Interested in appropriate data structures (for attributes) and algorithms (for operations),Class extender,Interested in how to extend a class to solve a new problem or to adapt to a change in application domain,Class user,Interested in signatures of class operations and conditions, under which they can be invoked,NOT interested in implementation of class (feature, not a bug!),Why distinguish Users of Class Diagrams?,Models often dont distinguish between application classes and solution classes,Reason,: Modeling languages like UML allow use of both types of classes in same model,“address book“, “array,Preferred,: No solution classes in analysis model,Many systems dont distinguish between specification and implementation of a class,Reason,: Object-oriented programming languages allow simultaneous use of specification and implementation of a class,Preferred,: We distinguish between analysis model and object design model. Analysis model does not contain any implementation specification.,Analysis Model vs Object Design model,Analysis model constructed during analysis phase,Main stake holders: End user, customer, analyst,Class diagrams contain only application domain classes,Object design model (sometimes also called specification model) created during object design phase,Main stake holders: class specifiers, class implementors, class users and class extenders,Class diagrams contain application domain as well as solution domain classes,Analysis Model vs Object Design Model (2),Analysis model is the basis for communication between analysts, application domain experts and end users.,The object design model is the basis for communication between designers and implementors.,Summary,System modeling,Functional + object + dynamic modeling,Functional modeling,From scenarios to use cases to objects,Object modeling is the central activity,Class identification is a major activity of object modeling,Easy syntactic rules to find classes and objects (Abbots Technique),Summary cntd,Class diagrams are “center of the universe” for object-oriented developer,End user focuses more on functional model and usability,Analysts, designers and implementors have different modeling needs,There are three types of implementors with different roles during,Class implementor, extender, and user,