In this section, the discusion is about :
Packages
Owned Elements
Visibility
Importing & exporting
Standard package elements
Modeling groups of elements
Package—general-purpose mechanism for organizing elements into groups.
Composite relationship-Destroyed if enclosing package is destroyed
You can control the Visibility of the elements owned by a package just as you can control the visibility of the attributes and operations owned by a class. Packages that are friends to another may see all the elements of that package, no matter what their visibility. If an element is visible within a package, it is visible within all packages nested inside the package.
Standard Package Element: facade—only a view on some other package. framework—package consisting mainly of patterns. stub—a package that serves as a proxy for the public contents of another package. subsystem—a package representing an independent part of the system being modeled. system—a package representing the entire system being modeled.
You can download full chapter from this link: Download Lecture_OOM11
In this section, the discusion is about :
Interfaces, types, & roles
Interface vs. Abstract Class
Modeling the Seams of a System
Well-Structured Interface
Interface: a collection of operations that are used to specify a service of a class or a component. Type: a stereotype of a class used to specify a domain of objects, together with the operations applicable to the object. Role: the behavior of an entity participating in a particular context.
A well-structured interface: Is simple yet complete. Providing all the operations necessary yet sufficient to specify a single service. Is understandable, providing sufficient information. Is approachable, providing information to guide the user to its key properties without being overwhelmed by the details of a pile of operations.
You can download full chapter from this link: Download Lecture_OOM10
In this section, the discusion is about :
Advanced Concepts on:
-Dependency
-Generalization
-Association
-Realization
Eight Stereotypes of Dependency Among Classes; bind: the source instantiates the target template using the given actual parameters, derive: the source may be computed from the target, friend: the source is given special visibility into the target, instanceOf: the source object is an instance of the target classifier, instantiate: the source creates instances of the target, powertype: the target is a powertype of the source; a powertype is a classifier whose objects are all the children of a given paren, refine: the source is at a finer degree of abstraction than the target, use: the semantics of the source element depends on the semantics of the public part of the target
Generalization-One stereotype – implementation: the child inherits the implementation of the parent but does not make public nor support its interfaces
Association-Four Basic Adornments of Association: name, role, multiplicity, & aggregation.
Realization-A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out. Realization is sufficiently different from dependency, generalization, and association relationships that it is treated as a separate kind of relationship. Semantically, realization is somewhat of a cross between dependency and generalization, and its notation is a combination of the notation for dependency and generalization.
You can download full chapter from this link: Download Lecture_OOM9
In this section, the discusion is about :
Classes:
- Name.
- Attributes.
- Operations.
- Responsibilities.
Modeling techniques:
- Vocabulary.
- Responsibilities.
- Non-software things.
- Primitive types.
Classes is about Attributes,Operations, and Responsibilities. Modeling the vocabulary of a system. Modeling the distribution of responsibilities. Modeling non-software “things”. Modeling primitive types. Modeling quality abstractions.
Well-structured class; Provides a crisp abstraction drawn from vocabulary of problem or solution. Embodies small, well-defined set of responsibilities. Provides clear separation of the abstractions specification and implementation. Understandable and simple. Extensible and adaptable.
Drawing a UML class; Show only properties that are important in a specific context. Organize long lists of attributes and operations by grouping. Show related classes in the same diagrams.
.png)
