Your SlideShare is downloading. ×
  • Like
  • Save
Interfaces & Packages V2
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Interfaces & Packages V2


A ppt abt insight of Interfaces and Packages as per UML guidelines. Latter implementation in Java.

A ppt abt insight of Interfaces and Packages as per UML guidelines. Latter implementation in Java.

Published in Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. By Anjan K I Sem M.Tech CSE M.S.R.I.T
  • 2. Agenda
    • Interfaces
      • Key Terms
      • Understanding Interfaces
      • Common Modeling Techniques
    • Packages
      • Terms &Concepts
      • Modeling Techniques
  • 3. Three World Architecture
  • 4. Need For Interfaces
    • You wouldn’t like to live in place that requires rewiring just change a bulb.
    • A standard building practices should help build a building that can evolve over time. Evolution should be such that it doesn’t disturb existing structure.
    • Its important to build a software with a clear separation of concerns.
      • Specifying clear seams in your system
      • Pick standard library or framework to implement those interfaces.
    • Java, C# and CORBA IDL provides support to interfaces
  • 5. Key Terms in Interfaces
    • Interface – its collection of operations that are used to specify a service of a class or a component.
    • Type - stereotype of class is used to specify a domain of objects, together with the operations applicable to the objects.
    • A Stereotype is a conventional categorization of modeling entities. They are often applied to classes, associations, and methods. They provide a way of extending the UML; for defining your own modeling elements, specific to your problem.
  • 6. Key Terms (cont’d)
    • Role - is the behavior of an entity participating in a particular content.
    • Interfaces specify outer view of a package or sub-system.
    • Use of interfaces promotes code flexibility.
    • In Java , interfaces may not define any implementation. In C++ , interfaces may be built with purely abstract classes.
    • UML notation for interfaces allows visualize abstraction from any implementation
  • 7. Naming an Interface
    • Names – An interface name must be unique within its enclosing packages.
    • A name is textual string consisting of any number of letters, numbers and certain punctuation marks.
    • Interface name are short nouns or phrases and prepended with ‘I’.
    • Path name is interface name prefixed with the package name
    • Ex:- Sensors::Itarget
  • 8. Operations
    • Interface do not specify any structure nor do they specify any implementation.
    • Interface may have any number of operations and these may be adorned with visibility properties, stereotypes and constraints.
    • Normal visual interface representation is circle that suppress the display of operations. But stereotyped class, listing its operation in compartment may also be used for interface.
  • 9. Relationships
    • Interface may also participate in association, generalization and even inheritance.
    • A class or component may realize many interfaces. Realizing means that complete description of the operation is implemented in class or component.
    • Interface is similar to abstract classes but former strictly doesn’t allow any implementation within its scope.
  • 10. Understanding an Interface
    • Interface has signature like visibility, scope and semantics.
    • These properties may not be enough to understand a complex interface.
    • To supply more information about interface we can either attach a pre or post conditions or attach state machine to interface
  • 11. Type and Roles
    • Consider an example of class person, instance of this class can play role mother, employee, customer, manager and so on.
    • Instance of person as employee would have different set of properties than instance playing the role of mother .
    • Type is the stereotype of the class and use to specify the domain of objects together with operation applicable to the objects of that type.
  • 12. Common Modeling Techniques
    • Modeling seams in a system
      • Identifying seams in a system involves identifying those components that may change independently, without affecting the components on the other side.
    • To model seams in a system
      • Identify those tightly coupled components and draw line around them.
      • Refine the grouping by considering the impact when they are collaborated.
      • Package these logically related groups properly.
      • For each package identify the imports and exports relation sips
  • 13. Common Modeling Techniques
    • Diagram shows seams surrounding component ledger.dll
    • ILedger, IReports , ITransaction and IStreaming are the interfaces .
    • ILedger, IReports are exported.
    • ITransaction, IStreaming are imported .
  • 14. Modeling Static & Dynamic Types
    • Statically typed means type of the object is bound at the time the object is created.
    • Modeling static nature is visualized using class diagram.
    • Modeling dynamic type is sometimes useful to understand natural changes of business objects.
    • Changes of object can gain or lose type during its lifetime.
  • 15. How to model dynamic types
    • Specify different possible types of that object
    • Model all the roles of the class at any point of time
      • Explicitly type each role that the class plays
      • Specify the class-to-type relationship
    • Display the role of the instance in brackets below the object name
    • Show the change of role of the object with stereotype as become .
  • 16. Packages
    • A general-purpose mechanism for organizing elements into semantically related groups.
    • Logical groupings of entities.
    • Packages can be nested.
    • At the highest level, a package contains an architectural entity (e.g., User Interface, Business Domain, subsystem).
    • At the lowest level, a package may represent a single person s work.
    • Packages are part of the Java programming language.
  • 17. Terms & Concept - Names
    • Names – An package name must be unique from other packages.
    • A name is textual string consisting of any number of letters, numbers and certain punctuation marks.
    • Path name is package name prefixed with the package name in which it lives.
    • Ex:- Sensors::target
  • 18. Owned Elements
    • A package may own other elements like class, interface, components or even other packages.
    • Owning is a composite relationship – elements are declared in the package.
    • A package forms a namespace – same kind must be named uniquely within the context of its enclosing package.
    • Ex: package can have class named sensor and component named sensor
  • 19. Visibility
    • Visibility controls the accessibility of individual elements of package in case of import or export.
    • A protected element is prefixed with ‘#’ , private with ‘-’ and public with ‘+’.
  • 20. Import & Export
    • Consider two packages
    • A & B
      • A explicitly imports b means A has access to all elements of B. But B has to public and B can’t see A. Stereotype is <<import>>.
      • B is public package and has exported contains to A.
    • If an element is visible within a package then it also visible in the nesting hierarchy.
  • 21. Common Modeling Techniques
    • Modeling groups of elements
      • In particular architectural view scan for elements semantically closer to each other.
      • Enclose each of these in package
      • Decide about the visibility for each package and the accessing strategies.
      • Explicitly connect packages via dependencies.
      • Family packages needs to be connected with generalization/specializaton relationships.
  • 22. Modeling Architectural Views
    • Identify set of Architectural Views that are required for context.
    • Visualize, specify, construct, document the semantics of each view in to appropriate package.
    • Group them into their own packages
    • Typical dependencies is exhibited between elements of different views.
  • 23. Summary
    • Interfaces
      • Key Terms
      • Understanding Interfaces
      • Common Modeling Techniques
        • Modeling Seams in system
        • Modeling static and Dynamic typed
    • Packages
      • Terms &Concepts
      • Modeling Techniques
        • Modeling group of elements
        • Modeling Architectural views