UNIT 1 UNIFIED PROCESS AND USE CASE DIAGRAMS 0/0
Introduction to OOAD with OO Basics – Unified Process – UML diagrams – Use Case –Case study – the Next Gen POS system, Inception -Use case Modelling – Relating Use cases – include, extend and generalization – When to use Use-cases
UNIT II STATIC UML DIAGRAMS 0/1
Class Diagram–– Elaboration – Domain Model – Finding conceptual classes and description classes – Associations – Attributes – Domain model refinement – Finding conceptual class Hierarchies – Aggregation and Composition – Relationship between sequence diagrams and use cases – When to use Class Diagrams
UNIT III DYNAMIC AND IMPLEMENTATION UML DIAGRAMS 0/1
Dynamic Diagrams – UML interaction diagrams – System sequence diagram – Collaboration diagram – When to use Communication Diagrams – State machine diagram and Modelling –When to use State Diagrams – Activity diagram – When to use activity diagrams Implementation Diagrams – UML package diagram – When to use package diagrams – Component and Deployment Diagrams – When to use Component and Deployment diagrams
UNIT IV DESIGN PATTERNS 0/1
GRASP: Designing objects with responsibilities – Creator – Information expert – Low Coupling – High Cohesion – Controller Design Patterns – creational – factory method – structural – Bridge – Adapter – behavioural – Strategy – observer –Applying GoF design patterns – Mapping design to code
UNIT V TESTING 0/1
Object Oriented Methodologies – Software Quality Assurance – Impact of object orientation on Testing – Develop Test Cases and Test Plans
Domain Model in OOAD
A domain model is a visual representation of conceptual classes or real – situation objects in a domain [M095, Fowler96]. Domain models have also been called conceptual models (the term used in the first edition of this book), domain object models, and analysis object models.
- “A domain model is a representation of real-world conceptual classes, not of software components.”
- Domain modeling is a technique used to understand the project problem description and to translate the requirements of that project into software components of a solution. The software components are commonly implemented in an object oriented programming language.
- A domain model contains conceptual classes, associations between conceptual classes, and attributes of a conceptual class. “Informally, a conceptual class is an idea, thing, or object”.
The UP defines the Domain Model as one of the artifacts that may be created in the Business Modeling discipline. More precisely, the UP Domain Model is a specialization of the UP Business Object Model (BOM) “focusing on explaining ‘things’ and products important to a business domain” [RUP]. That is, a Domain Model focuses on one domain, such as POS related things. The more broad BOM, not covered in this introductory text and not something I encourage creating (because it can lead to too much up – front modeling), is an expanded, often very large and difficult to create, multi – domain model that covers the entire business and all its sub – domains.
Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. It provides a conceptual perspective. lt may show:
- domain objects or conceptual classes
- associations between conceptual classes
- attributes of conceptual classes
Domain models are the initial artifacts created in Object-Oriented-Analysis. An object has:
- state, and
An object can be
- related to other objects and
- complex (with sub-objects).
A class is a description of a set of objects that share the same attributes, operations/responsibilities, relationships and semantics.
Identifying objects in the problem domain is used to identify conceptual classes in the problem domain. Conceptual classes model entities in the problem domain, not in the software domain.
Identifying Conceptual Classes
- Modify or reuse an existing model.
- Use a conceptual class category list.
- Identify noun phrases.
- Physical or tangible objects: quiz, game piece, die
- Specification, designs, or description of things: game piece image, marking scheme
- transaction: game move, order item, work item grade
- roles of people: marker, instructor, player
- container of things: game board, card deck
- events: start turn, finish game
- rules and policy: games ruler, submit assignment policy
- records: work item grade
Using noun phrases
Conceptual class can be identified by studying the use case looking for relevant noun phrases. Just like search term used in an Internet search engine, not all nouns are relevant.
Some heuristics for identification are:
- terms that developers or users need to clarify in order to understand the use case,
- recurring nouns (higher frequency),
- real world entities that the system needs to track,
- real world activities
- data sources or sinks
Category List for Associations
- A is a physical part of B. Memory is part of a CPU.
- A is a logical part of B. The p tag is grouped by a div tag.
- A is contained in B. A card is in a deck.
- A is a description of B. A house plan describes a house.
- A is a line item of B. A part in a part list.
- A is reported in B. An error event is reported in a log.
- A is a member of B. A faculty member is a member of a department.
- A used B. Tax rules are used to calculate the total in a point of sales terminal.
- A communicates with B. A computer communicates with a printer.
Heuristics for Identifying Associations
Some heuristics for identifying associations are:
- examine verb phrases,
- ensure that the roles and association names are clear,
- only add an association if it impoves the understanding of the domain,
- wait until the list of associations are stable before considering the multipicity,
An attribute is a logical data (property) of an object (e.g., my eyes are hazel). Most attributes can be represented by simple data types (which are?).
Some heuristics for identifying attributes:
- an attribute is part of the state of an object (a car’s speed is 100 km/h, weight of a work item)
- attributes are required by the use case (i.e., ignore irrelevant attributes).
Judgment is required to separate attributes from associated classes.
Making a domain model
- Identify conceptual classes
- Draw the class diagram
- Add any associations between classes
- Add attributes (properties) to the classes
Larman suggest that domain modeling should be similar to map making.
- use existing names (do not invent your own)
- exclude irrelevant features (that is the basis of modeling)
- do not add things that are not there.