INTRODUCTION TO SOFTWARE ENGINEERING • Authors: William M. Buchanan Joseph Picone • Contact Information: ECE 4512 / 4522 Box 9571 Mississippi State University Mississippi State, Mississippi 39762 Tel: 662-325-3149 Fax: 662-325-2298 DESIGN I • Email: {buchanan, picone}@ece.msstate.edu
23
Embed
INTRODUCTION TO SOFTWARE ENGINEERING Authors: William M. Buchanan Joseph Picone Contact Information: ECE 4512 / 4522 Box 9571 Mississippi State University.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• Use Cases: two use cases representing correct (“sunny”) and problematic (“rainy”) behavior
• Information Model: a diagram of how externally visible objects interact with one another
• Process Model: a detailed state machine showing how one of your most interesting objects is implemented
OVERVIEWBILL’S AMAZING VENDING MACHINE
OVERVIEWUSE CASES
OVERVIEWINFORMATION MODEL
OVERVIEWSTATE AND PROCESS MODEL
OVERVIEWOBJECT COMMUNICATION MODEL
• Labeled line drawings or pictures of your externally visible objects
Picture or Labeled Line Drawing
USE CASESFIRST DELIVERABLE: PHYSICAL MODEL
USE CASESDESCRIBES USER INTERACTIONS
USE CASESSTATE MACHINE REPRESENTATION
USE CASESMODELING DATA FLOW
USE CASESSECOND DELIVERABLE
INFORMATION MODELRELATIONSHIPS, OBJECTS, ATTRIBUTES
INFORMATION MODELRELATIONSHIPS, OBJECTS, ATTRIBUTES
• Consists of objects (e.g., attributes) and relationships (e.g., one-to-one, one-to-many)
• Object definition: a set of real-world things with common characteristics; all instances of an object behave the same
• Objects are:Tangible things that make up the problemRoles played by people or organizations Incidents (e.g. accidents, system crashes, service calls) Interactions with a transaction or contract quality (e.g.,
purchase related to buyer, seller, and thing purchased)Table Specifications (e.g., definition of attributes) Designed through an iterative process
INFORMATION MODELPROPERTIES
INFORMATION MODELKEYS TO SUCCESS
• Imagine you’re a specific instance of an object when evaluating relationships; e.g. one-to-one, one-to-many, etc.
• Answer questions about relationships from the mindset of an object instance
• Understand that relationships represent information exchange agreements between objects
• Don’t create an object unless you’re absolutely convinced you’ve got to have it
• Objects are work - more often than not, a lot of work
INFORMATION MODELTHIRD DELIVERABLE
PROCESS MODEL
• A different way to see, discover, and describe the same old problems
• Describe the solution in terms of the problem• OOA Models represent a higher layer of abstraction• When used in product development, the goal is to
maintain the models, not the code
Object-oriented analysis describes the problem using coupled graphical equations: information, state, and process models