Object Oriented Analysis and Design CHAPTERS 8 9 BASICS INTRO TO DOMAIN MODELS 1 What will we learn The basics of OOA OOD some key factors that are important in Inception and Elaboration The Domain Model what it is how to start to build one from scratch 2 Inception Phase Produces A short requirements workshop where most actors and goals are identified and use cases named Brief descriptions of use cases perhaps fully dressed versions for 10 of the critical ones Identification of high risk requirements risk list First drafts of Vision and Supplementary Specification artifacts Prototypes if needed e g UI High level candidate architecture Recommendation on build buy for some components Agreement on first iteration plan 3 Elaboration Core risky architecture components are built and tested Majority of requirements are discovered and stabilized Major risks are mitigated or retired Note risk may mean critical business function All code that is developed in this phase is production quality it is added to in later iterations Architectural baseline early versions of the architecture executable production quality Build the core architecture resolve high risk elements define most requirements and estimate the overall schedule and resources 4 Elaboration Artifacts Domain Model visualization of domain concepts Design Model Series of diagrams that describes the logical design Class definition diagrams object interaction diagrams package diagrams etc Software Architecture Document Summary of outstanding design ideas and their motivation in the system basically used as a learning tool Data Model may include database schema mapping between object and non object representations Use Case Model details of high level use cases first begun in Inception 5 Case Study NextGen POS Requirements Inception Key Decisions made during Inception plans for first iteration Implement basic key scenario of Process Sale use case entering items and receiving cash payment Implement Start Up use case to initialize the system No collaboration with external services at this point No complex pricing rules Notice that for the first iteration the use case is limited it will be expanded in later iterations 6 Case Study Monopoly Requirements Inception Implement basic key scenario of Play Monopoly Game use case 2 8 players Play for 20 rounds Each round each player takes one turn During a turn the player advances his her piece clockwise around the board a number of squares equal to the number rolled on two six sided dice The results of each player s roll is displayed The display includes the name of the player and the value of the roll When a player lands on a square the player s name and the name of the square are displayed There is no money winner or loser no properties to buy or rent no special squares There are 40 squares on the board One is named Go the others are simply numbered as Square 1 Square 2 Square 39 The only user input required is the number of players 7 Case Study Elevator Control System Inception Key Decisions made during Inception plans for first iteration Do not implement logging functionality or emergency override yet Critical requirements can the system interact with the mechanical systems to move the cabins and open close the doors First use cases User requests cabin user requests floor and cabin moves to floor door obstruction mechanism 8 Domain Model Introduction Very important model in OOA started after some key use cases have been developed Illustrates the important concepts in the Domain and will inspire the design of some software objects Also provides input to other artifacts Use Case Model operations contracts TBD Glossary Design Model Sequence Diagrams 9 concept or domain object Sales LineItem 1 0 1 quantity Item Records sale of 1 association Stocked in Contained in 1 1 Sale attributes date time Store address name 0 1 1 1 Houses Paid by 1 Payment This diagram shows an example of a an early Domain Model for the POS system 1 Register Captured on 1 amount 10 Note We will be using the UML diagrams we saw earlier The Domain Model appears to capture the important conceptual classes that make up the domain We will see how to identify these shortly The model also shows how these classes inter relate to each other Key aspect of OOA Identifying a rich set of conceptual classes Remember this is an iterative approach don t need the entire Domain Model created at once The model is refined over the iterations in the Elaboration Phase 11 Domain Model Definition The Domain Model can be thought of as a visual representation of conceptual classes or real situation objects in the domain i e the real world In UP the term Domain Model means a representation of real situation conceptual classes not software objects The term does not mean a set of diagrams describing software classes the domain layer of the software architecture or software objects with responsibilities This artifact is created in the Business Modeling discipline Think of as a visual dictionary describing the domain important abstractions domain vocabulary and information content 12 Observations Again when building a Domain Model avoid making it look like a class definition diagram Leave off software entities like databases and any known software objects Use conceptual level UML diagrams leave out methods and attribute details Conceptual Class An idea thing object Has a Symbol i e a name or image Has Intention the purpose in the domain what it does why it is there Has Extension a set of examples to which the conceptual class applies 13 Conceptual Class Example concept s symbol Sale date time A sale represents the event of a purchase transaction It has a date and time concept s intension sale 1 sale 2 sale 3 concept s extension sale 4 14 UP Domain Model Stakeholder s view of the noteworthy concepts in the domain A Payment in the Domain Model is a concept but a Payment in the Design Model is a software class They are not the same thing but the former inspired the naming and definition of the latter Payment 1 amount Sale date time inspires objects and names in This reduces the representational gap This is one of the big ideas in object technology 1 Pays for Payment amount Money getBalance Money Sale 1 Pays for 1 The difference between domain model and design model UML used in two different ways date Date startTime Time getTotal Money UP Design Model The object oriented developer has taken inspiration from the real world domain in creating software classes
View Full Document
Unlocking...