DOC PREVIEW
Toronto CSC 302 - Lecture 2 - Introduction to Modeling

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1Lecture 2:Introduction to Modeling Why Build Models? What types of Models to build Intro to UML Class Diagrams Reverse Engineering…University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2Getting started You’ve just joined an ongoing project Where do you start? (oh, BTW, the project doesn’t really have any documentation) Reverse Engineering: Recover design information from the code Create higher level views to improve understanding E.g. Structure of the code Code Dependencies Components and couplings E.g. Behaviour of the code Execution traces State machines models of complex objects E.g. Function of the code What functions does it provide to the user?2University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3Why build models? Modelling can guide your exploration: It can help you figure out what questions to ask It can help to reveal key design decisions Modelling can help to uncover problems Inconsistency in the models can reveal interesting things… e.g. conflicting or infeasible requirements e.g. confusion over terminology, scope, etc e.g. disagreements between stakeholders Modelling can help us check our understanding Reason over the model to understand its consequences Does it have the properties we expect? Animate the model to help us visualize/validate the requirements Modelling can help us communicate Provides useful abstracts that focus on the point you want to make …without overwhelming people with detailUniversity of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4Dealing with problem complexity Abstraction Ignore detail to see the big picture Treat objects as the same by ignoring certain differences (beware: every abstraction involves choice over what is important) Decomposition Partition a problem into independent pieces, to study separately (beware: the parts are rarely independent really) Projection Separate different concerns (views) and describe them separately Different from decomposition as it does not partition the problem space (beware: different views will be inconsistent most of the time) Modularization Choose structures that are stable over time, to localize change (beware: any structure will make some changes easier and others harder)3University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5the Unified Modelling Language (UML) Third generation OO method Booch, Rumbaugh & Jacobson are principal authors Still evolving (currently version 2.0) Attempt to standardize the proliferation of OO variants Is purely a notation No modelling method associated with it! Was intended as a design notation Has become an industry standard But is primarily promoted by IBM/Rational (who sell lots of UML tools, services) Has a standardized meta-model Use case diagrams Class diagrams Message sequence charts Activity diagrams State Diagrams Module Diagrams Platform diagrams …University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6UML viewsClass Diagramsinformation structure;relationships betweendata items;modular structure forthe system;Statechartsresponses to events;dynamic behavior;event ordering,reachability,deadlock, etc.Activity diagramsbusiness processes;concurrency andsynchronization;dependenciesbetween tasks;Sequence Diagramsindividual scenario;interactions betweenusers and system;Sequencing ofmessages;Use Casesuser’s view;Lists functions;visual overview of themain requirements;4University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7Intro: Object Classes in UML:patientNameDate of Birthphysicianhistory:in-patientRoomBedTreatmentsfood prefs:out-patientLast visitnext visitprescriptions:patientNameDate of Birthphysicianhistory:heartNatural/artif.Orig/implantnormal bpm:eyesNatural/artif.Visioncolour:kidneyNatural/artif.Orig/implantnumberSource: Adapted from Davis, 1990, p67-6810..10..21..20..1 0..1Generalization (an abstraction hierarchy)Aggregation(a partitioning hierarchy)University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8:patientNameDate of BirthHeightWeight:In-patientRoomBedPhysician:Out-patientLast visitnext visitphysician:heartNormal bpmBlood type:eyeColourDiameterCorrection:kidneyOperational?generalizationaggregationClass nameattributesservices0..111..20..10..20..1multiplicities:organNatural/artif.Orig/implantdonor5University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9What are classes? A class describes a group of objects with similar properties (attributes), common behaviour (operations), common relationships to other objects, and common meaning (“semantics”). Examples employee: has a name, employee# and department; an employee is hired, and fired; anemployee works in one or more projects:employeenameemployee#departmenthire()fire()assignproject()Name (mandatory)Attributes (optional)Operations (optional)University of TorontoDepartment of Computer Science© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10Fred_Bloggs:Employeename: Fred BloggsEmployee #: 234609234Department: MarketingObjects vs. Classes


View Full Document

Toronto CSC 302 - Lecture 2 - Introduction to Modeling

Documents in this Course
Load more
Download Lecture 2 - Introduction to Modeling
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 2 - Introduction to Modeling and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 2 - Introduction to Modeling 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?