Scribd
Upload
38 views

Object-Oriented Software Engineering

Object-Oriented Software Engineering Design Road involves beginning with a Domain Model that describes the conceptual classes and objects in the problem domain, followed by System Diagram(s) and OO Design Model(s). The Domain Model is a visual representation of the domain's conceptual classes and objects without software methods or attributes. It is created by identifying noun phrases from use cases and discussions with domain experts to capture the key concepts. The Design Model then evolves these concepts into more specific software classes and associations between them to describe the system design. There is no single correct solution, and iterative refinement is often needed to develop a high-quality domain and design model.

Uploaded by

Saim Khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
38 views

Object-Oriented Software Engineering

Object-Oriented Software Engineering Design Road involves beginning with a Domain Model that describes the conceptual classes and objects in the problem domain, followed by System Diagram(s) and OO Design Model(s). The Domain Model is a visual representation of the domain's conceptual classes and objects without software methods or attributes. It is created by identifying noun phrases from use cases and discussions with domain experts to capture the key concepts. The Design Model then evolves these concepts into more specific software classes and associations between them to describe the system design. There is no single correct solution, and iterative refinement is often needed to develop a high-quality domain and design model.

Uploaded by

Saim Khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 27

Object-Oriented Software

Engineering
Design Road
• Beginning the design
• Domain Model describes the
domain (context)
• It is followed by the System
Diagram(s)
• Then follows the OO Design
Model(s)
Domain Model
• Domain: A domain is a field of study that defines a set of common
requirements, terminology, and functionality for
any software program
• Domain Model: Visual representation of conceptual classes or real-
situation objects in a domain.
• The objects (conceptual classes) of the domain are not software objects
(classes)
• In UML, the Domain Model is illustrated with a set of class diagrams without
method.
• Also known as Visual Dictionary.
Domain Model
• Conceptual Class: Idea, thing or object
• It may be considered in terms of:
• Symbol —words or images representing the conceptual class
• Visual depiction, diagram
• Intension —the definition of the conceptual class
• Comprehensive definition
• Extension —the set of examples to which the conceptual class
applies
• Extensive definition
Domain Model
Domain Model
• Conceptual classes only!
• Not in domain model
• Software artifacts
• Windows, databases, etc.
• Unless domain is software
• Responsibilities or methods
• They are part of the design and the software
Drawing Domain Model
Drawing Domain Model
Drawing Domain Model
Drawing Domain Model
Drawing Domain Model
Drawing Domain Model
• Pick exact, specific names for objects, associations, etc
• Attributes should have trivial types (numbers, text, etc)
• Keep the most relevant associations in the DM
• Encapsulation —don't connect everything to everything!
• Objects should have strong internal cohesion (attributes)
• Objects should be associated to few other objects (low coupling)
• Problem: where do we get our objects from?
Getting the Concepts
• Reuse existing models
• Copy or adapt existing, well accepted models
• Use existing DM when modifying a system
• Identify noun phrases ( easy! )
• Pick nouns, events
• Fully dressed use cases are great source
• Beware : natural language is imprecise
Getting the Concepts
Class lists consist of • Catalogs
common taxonomy
• Containers of things
• Business transactions
• Transaction line items • Things in a container
• Products, services • Other related systems
• Place of transaction • Fiduciary records (work,
• Noteworthy events contracts, finances, etc)
• Physical objects • Financial instruments
Descriptions of things
• Reference documents
(schedules, manuals, etc)
Getting the Concepts
Getting the Concepts
Getting the Concepts
• Using nouns or noun phrases has [almost] no learning curve ( easy! )
• Verbs often imply associations
• This method is as imperfect as natural language
• Also serves to check use cases and requirements though
• Solutions
• Refer to class list
• Talk to domain expert
Getting the Concepts
We may infer more concepts from what we have
• Patch the holes —are there holes in the design?
• Specialize —are there interesting subclasses?
• Generalize —are there interesting super classes?
• Decompose —can an object be described in terms of other, contained
objects? ( Many meanings to this )
• Compose —is a collection of given objects relevant?
• Fix imperfections —next slides
Getting the Concepts
Getting the Concepts
Getting the Concepts
Getting the Concepts
Getting the Concepts
Example:
Domain Model VS Design Model
Design Model
• We will use a detailed Class Diagram to describe the Design
Model
• We will evolve and infer OO classes from the concepts
• We might drop concepts as well
• Other classes will come from system needs
• The associations will be much more specific
• Code can be partially inferred from Design Model
Suggestions
• No single correct answer —no exact science either!
• It might take to become familiar with the ideas
• It may be good to start with a simple domain model
• Then, check what is wrong—fix
• Fixing may add components
• Iterate until good quality
• Don't connect all to all!

You might also like