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

  • 1,260 views
Published

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

Views

Total Views
1,260
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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