Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Interfaces & Packages V2


Published on

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

Published in: Education, Technology
  • Be the first to comment

Interfaces & Packages V2

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