DOC PREVIEW
Toronto CSC 340 - Lecture 13 - Object Oriented Modelling

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 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 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

University of Toronto Reminder we are modeling this and this but not this Application Domain Object Oriented Analysis Machine Domain C computers D domain properties Rationale P programs R requirements Identifying Classes Attributes and Operations Department of Computer Science Requirements Domain Models Lecture 13 Object Oriented Modelling University of Toronto Department of Computer Science Our analysis models should Class Diagrams represent people physical things and concepts important to the analyst s understanding of what is going on in the application domain Associations show connections and interactions among these people things and relevant concepts Multiplicity Aggregation show the business situation in enough detail to evaluate possible designs Composition be organized to be useful later during design and implementation of the software Generalization allow us to check whether the functions we will include in the specification will satisfy the requirements test our understanding of how the new system will interact with the world 1 Easterbrook 2004 University of Toronto Department of Computer Science 2 Easterbrook 2004 University of Toronto Object Oriented Analysis Department of Computer Science Nearly anything can be an object Source Adapted from Pressman 1994 p242 Background Model the requirements in terms of objects and the services they provide E g people devices other systems Applied to modelling the application domain rather than the program Motivation Things E g division group team etc Occurrences or Events that occur in the context of the system OO emphasizes importance of well defined interfaces between objects E g transfer of resources a control action etc compared to ambiguities of dataflow relationships Roles played by people who interact with the system NOTE OO applies to requirements engineering because it is a modeling tool But we are modeling domain objects not the design of the new system 3 Easterbrook 2004 Places that establish the context of the problem being modeled E g manufacturing floor loading dock etc E g reports displays signals etc As a system evolves the functions it performs need to be changed more often than the objects on which they operate a model based on objects rather than functions will be more stable over time hence the claim that object oriented designs are more maintainable Organizational Units that are relevant to the application that are part of the domain being modeled OO is claimed to be more natural Easterbrook 2004 that interact with the system being modeled Grew out of object oriented design External Entities Structures that define a class or assembly of objects E g sensors four wheeled vehicles computers etc Some things cannot be objects procedures e g print invert etc attributes e g blue 50Mb etc 4 1 University of Toronto University of Toronto Department of Computer Science Department of Computer Science What are classes Finding Classes A class describes a group of objects with similar properties attributes Look for nouns and noun phrases in stakeholders descriptions of the problem common behaviour operations include in the model if they explain the nature or structure of information in the application common relationships to other objects and common meaning semantics Examples employee name employee department hire fire assignproject Users and other stakeholders Analysis patterns Name mandatory It s better to include many candidate classes at first You can always eliminate them later if they turn out not to be useful Explicitly deciding to discard classes is better than just not thinking about them Operations optional 5 Easterbrook 2004 University of Toronto Finding classes from other sources Reviewing background information employee has a name employee and department an employee is hired and fired an employee works in one or more projects Attributes optional Finding classes source data University of Toronto Department of Computer Science Selecting Classes Department of Computer Science Objects vs Classes Discard classes for concepts which Are beyond the scope of the analysis The instances of a class are called objects Objects are represented as Refer to the system as a whole Fred Bloggs Employee Duplicate other classes Are too vague or too specific name Fred Bloggs Employee 234609234 Department Marketing e g have too many or too few instances Coad Yourdon s criteria Retained information Will the system need to remember information about this class of objects Needed Services Do objects in this class have identifiable operations that change the values of their attributes Multiple Attributes If the class only has one attribute it may be better represented as an attribute of another class Common Attributes Does the class have attributes that are shared with all instances of its objects Common Operations Does the class have operations that are shared with all instances of its objects Two different objects may have identical attribute values like two people with identical name and address Objects have associations with other objects E g Fred Bloggs employee is associated with the KillerApp project object But we will capture these relationships at the class level why Note Make sure attributes are associated with the right class External entities that produce or consume information essential to the system should be included as classes Easterbrook 2004 6 Easterbrook 2004 E g you don t want both managerName and manager as attributes of Project Why 7 Easterbrook 2004 8 2 University of Toronto University of Toronto Department of Computer Science Associations Association Multiplicity Objects do not exist in isolation from one another A relationship represents a connection among things If yes then the association is optional at the Staff end zero or one If a campaign cannot exist without a member of staff to manage it Association Aggregation and Composition Generalization Dependency Realization then it is not optional if it must be managed by one and only one member of staff then we show it like this exactly one What about the other end of the association Note The last two are not useful during requirements analysis Ask questions about the associations Can a campaign exist without a member of staff to manage it In UML there are different types of relationships Does every member of staff have to manage exactly one campaign Class diagrams show classes and their relationships No So the correct multiplicity is zero or more Some examples of


View Full Document

Toronto CSC 340 - Lecture 13 - Object Oriented Modelling

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download Lecture 13 - Object Oriented Modelling
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 13 - Object Oriented Modelling 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 13 - Object Oriented Modelling 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?