1 / 42

Design Model Lecture p6 T120B029 200 4 pavasario sem.

Design Model Lecture p6 T120B029 200 4 pavasario sem. Main processes of the team assignment. requirements analysis. design process. coding. testing. design document. problem description. requirements document. Used technique: UML use case diagrams UML activity diagrams.

callie-rice
Download Presentation

Design Model Lecture p6 T120B029 200 4 pavasario sem.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design Model Lecture p6T120B0292004 pavasario sem.

  2. Main processes of the team assignment requirements analysis design process coding testing design document problem description requirements document Used technique: UML use case diagrams UML activity diagrams Used technique: UML component diagrams, UML class diagrams, UML state diagrams UML sequence diagrams, UML activity diagrams Used languages: Java C++ … T120B029 T120B029

  3. The Design Model • The analysis model represents the system in terms of objects that domain experts know. • The design model represents the same system, but at a level of abstraction closer to the source code. • For example, the classes in the design model have a language and model properties assigned, which define the mapping to code. T120B029 T120B029

  4. Structural Diagrams Used to visualize, specify, construct, document static aspects of system • class diagram • package diagram [not standard UML] • object diagram • component diagram • deployment diagram T120B029

  5. Common Uses of Class Diagrams • to model vocabulary of the system, in terms of which abstractions are part of the system and which fall outside its boundaries • to model simple collaborations (societies of elements that work together to provide cooperative behavior) • to model logical database schema (blueprint for conceptual design of database) T120B029

  6. Class diagram • Central for OO modeling • Shows static structure of the system • Types (!) of objects • Static relationships • Association (e.g.: a company has many employees) • Generalization (subtypes) (e.g.: an employee is a kind of person) • Dependencies (e.g.: a company is using trucks to ship products) T120B029

  7. Three Perspectives We can look at classes from these perspectives: • Conceptual (OOAnalysis) • Shows concepts of the domain • Should be independent from implementation • Specification (OODesign) • General structure of the running system • Interfaces of software (types, not classes) • Often: Best perspective • Implementation (OOProgramming) • Structure of the implementation (classes) • Most often used Try to draw from a clear, single perspective T120B029

  8. What are classes? • A class describes a set of objects with an equivalent role or roles in a system • Sources for objects: tangible real-world things, roles, events, interactions T120B029

  9. Class • A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. • An attribute is a named property of a class that describes a range of values that instances of the property may hold. • An operation is a service that can be requested from an object to affect behavior. T120B029

  10. ? • Why do we need class models? • What is a good class model? • How to identify classes? • What classes consist of? • What are associations and what types of associations exist? • What are interfaces? T120B029

  11. Identifying Classes • Identify class candidates by picking all nouns and noun phrases out of system requirements specification • Use singular form • Discard anything that does not seem appropriate: redundant, vague, event or operation, outside of scope, attribute T120B029

  12. Identifying Objects • Objective: System must satisfy current requirements • Solution: Every required behavior must be provided by some objects • Objective: System must be easy to maintain and adapt to future requirements T120B029

  13. Name Attributes Operations Class Notation T120B029

  14. Name Attributes Operations Alternative Class Notations Name Attributes Name Operations Responsibilities italics abstract T120B029

  15. Attributes and Operations • Attributes and Operations • Operations define the ways in which objects may interact • Operation signatures – how are they defined? • Attributes are the data contained in an object • Both can be public, protected or private T120B029

  16. Customer name address creditRating Attributes • Conceptual: Indicates that customer have names • Specification: Customer can tell you the name and set it(short for get/set methods) • Implementation: An instance variable is available T120B029

  17. Operations • Services that a class knows to carry out • Correspond to messages of the class (or IF) • Conceptual level • principal responsibilities • Specification level • public messages = interface of the class • Normally: Don’t show operations that manipulate attributes T120B029

  18. UML syntax for operations visibility name (parameter list) : return-type-expression + assignAgent (a : Agent) : Boolean • visibility: public (+), protected (#), private (-) • Interpretation is language dependent • Not needed on conceptual level • name: string • parameter list: arguments (syntax as in attributes) • return-type-expression: language-dependent specification T120B029

  19. number : String Order dateReceived Customer isPrepaid name address price : Money * 1 Responsibilities - specifies orders Responsibilities - lists the customer Operations vs. Responsibilities • Conceptual: Operations should specify responsibilities, not IF, e.g.: • The Customer specifies the Orders • The Orders list the Customer T120B029

  20. Relationships connections between classes • dependency • generalization • association T120B029

  21. Associations (1) • Associations correspond to verbs, as classes correspond to nouns • Class A and class B are associated if • An object of class A sends a message to an object of class B • An object of class A creates an object of class B • An object of class A has an attribute whose vales are objects of or collections of objects of class B • An object of class A receives a message with an object of class B as an argument T120B029

  22. Person Company Association(2) An association is a structural relationship within which classes or objects are connected to each other. (An association between objects is called a link.) T120B029

  23. Job description dateHired salary Association Classes An association class has properties of both an association and a class. Person Company T120B029

  24. Association Adornments • name • role • multiplicity • aggregation • composition T120B029

  25. works for Person Company Association Name describes nature of relationship: can also show direction to read name: works for Person Company T120B029

  26. Association Roles(1) • describe “faces” that classes present to each other within association • class can play same or different roles within different associations employee Person Company employer T120B029

  27. Association Roles(2) • Roles clarify participation of each class in association T120B029

  28. Association Multiplicity(1) • possible values same as for classes: explicit value, range, or * for “many” • Example: a Person is employed by one Company; a Company employs one or more Persons 1..* Person Company 1 T120B029

  29. Association Multiplicity(2) • Multiplicity of an association: • An exact number • A range of numbers • An arbitrary, unspecified number (*) T120B029

  30. Generalization and Specialization • Generalization relationship between two classes indicates that one class in more specific than the other in representing similar objects How to check whether generalization exists: “every Instructor is a Person” • Inheritance is a way to implement generalization T120B029

  31. Generalization A generalization is a “kind of” or “is a” relationship between a general thing (superclass or parent) and a more specific thing (subclass or child). Shape Circle Rectangle T120B029

  32. Dependency A dependency is a “using” relationship within which the change in the specification of one class may affect another class that uses it. Example: one class uses another in operation Window Event handleEvent() T120B029

  33. Aggregation and Composition • Aggregation: an object of one class is a part of another class • Composition: a strong form of aggregation – an object of one class is owned by an object of another class T120B029

  34. Aggregation Aggregation is a “whole/part” or “has a” relationship within which one class represents a larger thing that consists of smaller things. Company Department T120B029

  35. Composition Composition is a special form of aggregation within which the parts are inseparable from the whole. Window Frame T120B029

  36. Observer «interface» Observer update() Realization A realization is a relationship between an interface and the class that provides the interface’s services. A class may realize many interfaces. TargetTracker T120B029

  37. T120B029

  38. «interface» Observer update() Interfaces in UML (1) An interface is a named collection of operations used to specify a service of a class without dictating its implementation. Observer T120B029

  39. Interfaces in UML (2) • An interface specifies some operations of a model element (a class) that are visible outside of a class • An interface class cannot have any attributes T120B029

  40. <<interface>>DataInput close() InputStream{abstract} OrderReader Dependency Generalization DataInputStream Realization Interfaces in UML (3) • Stereotype <<interface>> T120B029

  41. Interfaces in UML (4) Lollipops (“short-hand notation”) DataInput OrderReader Interface DataInputStream Dependency T120B029

  42. Interface Relationships An interface may participate in generalization, association, and dependency relationships. Tracker Observer Periodic Observer Observation T120B029

More Related