Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 1.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Object-Oriented Analysis and Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Chapter 1 Object Oriented Analysis and Design. UML, Patterns, and Object-Oriented Analysis and Design  The essential skills for the creation of well-designed,
March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
Introduction To System Analysis and Design
© Lethbridge/Laganière 2001 Chapter 9: Architecting and designing software1 Layers Data from IBM-Rational and Craig Larman…
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
Satzinger, Jackson, and Burd Object-Orieneted Analysis & Design
Object-Oriented Analysis and Design
March R McFadyen1 Figure 30.2 Layers in NextGen They only have three layers in this architecture Each layer is shown as a UML Package No separate.
Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative Development Part III Elaboration Iteration I – Basic1.
Chapter 7: The Object-Oriented Approach to Requirements
Introduction To System Analysis and design
CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Tuesday Class will start momentarily. Please Stand By … CS 8532: Advanced Software.
The Design Discipline.
Chapter 13 Starting Design: Logical Architecture and UML Package Diagrams.
Systems Analysis and Design in a Changing World, Fifth Edition
Chapter 18 Object Design Examples with GRASP. Objectives Design use case realizations –A use-case realization describes how a particular use case is realized.
BTS430 Systems Analysis and Design using UML Domain Model Part 1—Finding Conceptual Classes.
Systems Analysis and Design in a Changing World, 6th Edition
12 Systems Analysis and Design in a Changing World, Fifth Edition.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
1 On to Object Design Chapter 14 Applying UML and Patterns.
Introduction To System Analysis and Design
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Systems Analysis and Design in a Changing World, 3rd Edition
Chapter 13 Logical Architecture and UML Package Diagrams 1CS6359 Fall 2012 John Cole.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
GRASP: Designing Objects with Responsibilities
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
1 COMP 350: Object Oriented Analysis and Design Lecture 1Introduction References: Craig Larman Chapter 1.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
What to remember from Chap 13 (Logical architecture)
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Object Oriented Design Jerry KotubaSYST Object Oriented Methodologies1.
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
DOMAIN MODEL: ADDING ATTRIBUTES Identify attributes in a domain model. Distinguish between correct and incorrect attributes.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design.
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
TK2023 Object-Oriented Software Engineering CHAPTER 8 LOGICAL ARCHITECTURE.
Chapters 10, 11 SSD (Revision) SD DCD Exam Object-Oriented Design.
INFO 620Lecture #71 Information Systems Analysis and Design Design Class Diagrams and others INFO 620 Glenn Booker.
Object-Oriented Application Development Using VB.NET 1 Chapter 5 Object-Oriented Analysis and Design.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
OO Methodology Elaboration Phase Iteration 1- Part 3.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
Basic Characteristics of Object-Oriented Systems
Logical Architecture and UML Package Diagrams. The logical architecture is the large-scale organization of the software classes into packages, subsystems,
Object Design Examples with GRASP
Elaboration popo.
GRASP – Designing Objects with Responsibilities
Chapter 12: Collaboration Diagram - PART2
Unified Modeling Language
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
Object-Oriented Design
Introduction To System Analysis and Design PART 2
Starting Design: Logical Architecture and UML Package Diagrams
CS 8532: Advanced Software Engineering
Chapter 13 Logical Architecture.
Logical Architecture & UML Package Diagrams
Presentation transcript:

Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 1

What will we learn? Introduction to the Logical Architecture and layers How to use UML package diagrams Understanding the static versus dynamic object modeling 2

Moving from Analysis to Design So far we have studied … How to create use cases How to create a Domain Model How to create SSDs and Operations Contracts These are the main tools in OOA, i.e. they help explore and define what the system does We will now move to design, where we define how the system works Note that this may still be part of the Agile UP process: Analysis and design are occurring at the same time as requirements are refined 3

Analysis vs Design A bad domain model will mean bad communication of the what the system is; a bad design model often leads to a bad implementation Making the correct choices now becomes more important Here is where iterative development can help – constant feedback and requirements enhancement can help the design evolve correctly Note the initial requirements analysis phase may be very short, and of course coding can start immediately 4

Artifacts Interaction We are now ready to begin to build the Design Model artifact Key influences: Most of the artifacts we have already worked on influence the Design Model: Use-Case Model Vision Supplementary Specification Glossary Domain Model The Logical Architecture (LA) is part of the Design Model artifact, and is often shown using package diagrams (we will learn about these shortly) Note the interaction diagrams (which are dynamic) and class definition diagrams (which are static) are also part of the Design Model artifact 5

6

7

Logical Architecture The Logical Architecture is a large-scale organization of the software classes into packages, subsystems, and layers. Logical: Implies that there is no decision about how these elements are actually deployed on physical systems, i.e. how many computers will host the system, how they are connected, etc. The LA organizes the software classes into layers, which are just collections of classes Each layer is made up of similar classes that have similar responsibilities for a major aspect of the system Normally, the higher or upper layers call upon the services of the lower layers, but not viceversa 8

Logical Architecture: The Layer Model 9 NamePurpose User Interface (UI)Software objects that directly interact with the user, e.g. GUI interface forms Application Logic and Domain Objects Software objects representing domain concepts that fulfill application requirements, such as calculating a total Technical ServicesGeneral purpose objects and subsystems that provide supporting technical services, e.g. error logging or interfacing to a database. Usually reusable objects that are used across multiple applications These are types of layers – the actual model may have more

Logical Architecture In a strictly layered model, each layer only calls the services of the layer below it For information services, the layered model is usually considered relaxed For example, the GUI may utilize logging, or a form may directly access a database for a query We will primarily concentrate on the middle layer, the Domain or Application Logic layer For UI, we will primarily be concerned with how it interacts with the middle layer 10

UML Package Diagrams We saw this concept when we were developing domain models – it is a way to organize the model into sub-models, with a “folder” notation for easier reading Often used to illustrate the logical architecture Model a layer as a package The UML package diagram provides a way to group elements – can be used to group classes, other packages, etc. Common to show dependency between packages – use a UML dependency line (dashed arrow pointing towards depended-on package) UML package provides a namespace, which allows classes to be defined differently in different packages Some UML CASE tools will reverse engineer code into packages 11

12

13

Design with Layers The key benefit is that objects and classes are separated into cohesive units This reduces complexity – less coupling of objects We will see later that this is a good thing For us, the key question will be how to design the objects that make up the Application Layer in an OOD manner The basic approach is to define software objects with names and information similar to the real-world domain (Domain Model), and assign application logic responsibilities to them These types of software objects are called Domain Objects Represents something in the problem domain space, and has related application of business logic Often the Application Logic layer is called the Domain Layer for this reason 14

Domain Layer and Domain Model We look to the Domain Model for inspiration for the names and classes that will make up the Domain layer Note: Not all conceptual classes in the Domain Model need to have classes in the Domain Layer This is why we do the Domain Model – it helps close the gap between the software system and the real world model it is representing Also very useful to name objects and associations after their real world counterparts – easier to comprehend the software 15

16

Layer Do’s and Don’ts Don’t show external resources (like a database) in a layer at the bottom of the layer diagram – these resources should be included in the layer diagram as separate entities within an existing layer (e.g. the Technical Services) Model – View Separation: Don’t put application logic in UI objects, and don’t let non-UI objects reference UI objects Traditionally, the term model refers to the Domain Layer while the term view refers to the UI layer Generally, model objects do not have direct knowledge of view objects, but this can be relaxed. For example, in the POS, the Sale object should not directly send a message to a GUI window (but of course the other way is okay) This helps promote re-use by not connecting domain objects to applications (UI objects) 17

SSDs, System Operations, Layers Recall that SSDs were created from use cases to help explain how the system handles input events from the user In these diagrams, the internal objects of the UI layer are usually hidden, although in the actual design there will probably be some kind of GUI or web page to gather the input Normally, these UI objects will then forward the input information to objects in the Domain (or Application) Layer for processing These are the system event messages we see in the SSDs Example: In our POS system, if the Cashier is entering the items on a terminal (touchscreen or keyboard), there may be a Java Swing object ProcessSaleFrame that captures the information from the Cashier and forwards it to the Register See next slide for a diagram 18

19

Logical Architecture for POS and Monopoly The preceding diagram suggests a logical architecture for the POS system; we will study this in more detail in Chapter 34 after we expand our knowledge of OOD But the LA shown on the previous slide would actually work for the first “cash payment” only iteration of the POS For Monopoly, the LA would not really show anything useful – It is a very simple UI, Domain, Technical Services architecture See next slide for a more detailed view of what the POS LA will look like in our next iterations 20

21

Designing Objects There are two kinds of object models: dynamic and static Dynamic models help design the logic (i.e. the behavior) of the code or methods These are the UML interaction diagrams (sequence or communication) we have seen Static models help design the definition of packages, class names, attributes, and method signatures or operations (names and input parameters, return values – not method bodies) These are the UML Class diagrams Both types of models are usually created together in Agile UP Can start with dynamic model and then move to static to fill in details Dynamic models tend to be more challenging and useful – they explain the behavior, and will reveal the software objects that need to exist to make the behavior happen, as well as the messages/methods that allow these objects to communicate 22

23

Designing Objects (cont.) It is during the dynamic model creation stage that responsibility-driven design principles (like GRASP) are used Recall that one the critical aspects of OOD was how to assign responsibilities to the objects in our design – this is essentially what the GRASP principles help with Basic process: For each system event, create software classes (using the Domain Model for inspiration) that will be responsible for handling the event For static models, the most common tool is the UML class diagram Often created in parallel with the dynamic models Organized into packages, as we have already seen Remember, UML is a tool, not the actually design skill. Anyone can draw a UML diagram, but creating a good OO design is more challenging 24

Object-Oriented Design: Overview Start with the use cases, Domain Model (possibly), SSDs, operations contracts (possibly) Select a system operation (from the SSD, possibly detailed in an operations contract) Using design patterns (like GRASP or GoF), or general experience, create software classes that will allow the system to handle the responsibilities of the system operation Usually start with a dynamic model, like an sequence diagram or communication diagram The operations contract or use case will describe the “responsibilities” – i.e. what the system is supposed to do, or what changes in the system Use the Domain Model to inspire software objects that will create the desired behavior 25

Design Patterns: Introduction In software engineering, a design pattern is a general reusable solution to a commonly occurring problem Note: Not a code template or a reusable module These are descriptions for how to solve a problem The problems addressed by design patterns are commonly occurring problems in software design We will study two groups in this course: GRASP: General Responsibility Assignment Software Patterns (or Principles) GoF: Gang of Four Patterns, widely considered the fundamental patterns for OOD These will provide us with guidance on how to assign responsibilities to objects we want to design 26

The Model-View-Controller (MVC) Architecture Very common logical architecture, similar to what we just saw The View is the UI layer – it contains all the GUI objects, and has very little application logic Passes information down The Model – this is the layer that contains all of the logical functionality of the system – what it actually does The Controller – this is the “glue” layer between the View and the Model. Takes requests from the View, passes to the Model Takes information from the Model, passes to the View for display This architecture is popular because it promotes reuse of components 27

Takeaways from Chapter 12, 13, 14 Understand the logical architecture and the three main types of layers Understand the relationship between Domain Model and Domain Layer Understand the two types of design models (static and dynamic) 28

Next … GRASP: General Responsibility Assignment Software Patterns – Chapter 17 29