Packages.

Slides:



Advertisements
Similar presentations
Object orientation and persistent objects Dragos Chirila Finsiel Romania Copenhagen, 24 May 2004.
Advertisements

Chapter 10: Introduction to Inheritance
ITEC200 – Week03 Inheritance and Class Hierarchies.
UML – Class Diagrams.
1 © Wolfgang Pelz UML3 UML 3 Notations describe how to use reusable software. Package Component Deployment Node.
1 CS 426 Senior Projects Chapter 19: Interfaces and Components [Arlow & Neustadt 2005] February 28, 2008.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Introduction to UML Visual modeling Models and its importance
Aalborg Media Lab 23-Jun-15 Inheritance Lecture 10 Chapter 8.
Package Diagram CS537 Advanced Software Engineering Fall 2010 Prof. J Guo Presented By: Patel Vishrut Patel Harshil Gadhiya Yogesh Dhola Haresh.
©The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter Chapter 17 Animated Version Generics and Type Safety.
Session 24 Modeling the Development Environment Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 27, 2011 Presented by Hyewon Lim.
1 © Dennis Hart 2001 OOAD Packages, Dependencies & Interfaces Dr Dennis Hart.
Uml is made similar by the presence of four common mechanisms that apply consistently throughout the language. After constructing or developing the architecture.
UML Advanced Structural Modeling II
Part VII: Design Continuous
Relationships Relationships between objects and between classes.
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
8. Inheritance “Is-a” Relationship. Topics Creating Subclasses Overriding Methods Class Hierarchies Abstract Class Inheritance and GUIs The Timer Class.
Introduction to Java Chapter 7 - Classes & Object-oriented Programming1 Chapter 7 Classes and Object-Oriented Programming.
Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering.
Java Software Solutions Lewis and Loftus Chapter 9 1 Copyright 1997 by John Lewis and William Loftus. All rights reserved. Enhanced Class Design -- Introduction.
JAVA INTRODUCTION. What is Java? 1. Java is a Pure Object – Oriented language 2. Java is developing by existing languages like C and C++. How Java Differs.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Classes, Interfaces and Packages
Identifying classes, Packages and drawing class Diagrams, Object Diagrams and composite structure diagrams Week 07 1.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Geoff Holmes and Bernhard Pfahringer COMP206-08S General Programming 2.
Chapter 11: Abstract Data Types Lecture # 17. Chapter 11 Topics The Concept of Abstraction Advantages of Abstract Data Types Design Issues for Abstract.
Use Cases. 2 A use case... –Specifies the behavior of a system or some subset of a system. –Is a system-level function. –Does not indicative how the specified.
2-1 © Prentice Hall, 2004 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their.
UNIT-IV Designing Classes – Access Layer ‐ Object Storage ‐ Object Interoperability.
Modern Programming Tools And Techniques-I
Lecture 12 Inheritance.
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Chapter 5:Design Patterns
Coupling and Cohesion 1.
University of Central Florida COP 3330 Object Oriented Programming
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
Chapter 8 Analysis & Modeling
Java Programming: From Problem Analysis to Program Design,
INTRODUCTION TO OBJECT-ORIENTED PROGRAMMING (OOP) & CONCEPTS
The Object Oriented Approach to Design
Inheritance B.Ramamurthy 11/7/2018 B.Ramamurthy.
Use Case Realization Describes a collaboration among analysis classes that shows how a specific use case is realized Consists of flow-of-events analysis,
Chapter 19: Interfaces and Components
Abstract Data Types and Encapsulation Concepts
Module 11: Packages Lawrence Chung CS6359.OT1: Module 11.
Corresponds with Chapter 7
CBSE 2014 Modeling Components with UML
Introduction to Design Patterns Part 1
Chapter 9 Use Cases.
Use Cases.
Interfaces.
UNIT – V.
Class Diagrams.
Chapter 19: Interfaces and Components
Overriding Methods & Class Hierarchies
Java Programming, Second Edition
Chapter 19: Interfaces and Components
Design Yaodong Bi.
CIS 375 Bruce R. Maxim UM-Dearborn
Interfaces and Components
Chapter 19: Interfaces and Components
Creating and Using Classes
SPL – PS4 C++ Advanced OOP.
Presentation transcript:

Packages

Introduction As the number of elements in a design grows it is often necessary to group related elements together into packages. A package is a general-purpose mechanism for organizing elements into groups. Grouping like elements into packages is a technique for managing complexity. The items in a particular package should be semantically close and subject to change at the same time.

Introduction Package is synonymous with directory and folder. Graphically, a package is drawn as a tabbed folder. The visibility of individual elements within a package can vary. Packages are loosely coupled and highly cohesive. Packages, unlike classes, cannot be instantiated. Packages have no meaning in the problem domain. They are used to organize the various elements of the problem domain.

Terms and Concepts Names Owned elements Every package must have a name. The name is a text string. The name may be a simple name (Graphics.dll) or a path name (DllLibrary::Graphics.dll). Owned elements A package is a container that may contain other packages. (A directory may contain subdirectories). Package icons may be drawn inside other package icons. The elements contained directly within a package should have unique names.

Terms and Concepts Visibility Just as the members of a class may me declared as public, protected or private, the members of a package may be declared as public, protected or private. Public (+) - Visible to all. Provides the interface to the package. Protected (#) - Visible only to descendants in inheritance relationships. Private (-) - Not accessible outside the package.

Simple and Extended Packages

Owned Elements

Terms and Concepts Importing and Exporting Packages form a wall around their contents. Elements within a package cannot be arbitrarily accessed from outside the package, even if the element(s) are public. The public elements are known as exports. To access elements in a package, the package must be imported. Importing grants one-way permission for the elements in the importing package to access elements in the imported package. Imports are modeled as a dependency adorned with the stereotype <import>.

Importing and Exporting

Terms and Concepts Generalization Standard Elements Based on the same principle as generalization among classes. A package that is derived (inherits) from another package can access all of its public and protected members. Graphically, generalization between packages is represented the same way as generalization between classes. Standard Elements There are 5 pre-defined stereotypes that apply to packages: facade, framework, stub, subsystem and system.

Generalization

Common Modeling Techniques Package elements together that you wish to manipulate as a set. These elements will have similar semantics. The larger the system, the greater the need for multiple packages. Imagine how difficult it would be to comprehend a textbook that was not organized into chapters. When in doubt about the visibility of a package element, make it private. Look for relationships between packages. Packages may be used for architectural modeling.