OOAD, UML And RUP - Glarimy PDF Free Download

1y ago

25 Views

1 Downloads

1.24 MB

62 Pages

Report/dmca

Download PDF

Transcription

GlarimyOOAD, UML 2 & RUPKrishna Mohan Koyya, M.Tech, DBM, PMPTechnology Consultant & Corporate TrainerGlarimy Technology Services, Bangalore, Indiakrishna@glarimy.com www.glarimy.com091-9731 4231 66 2009, Glarimy. All rights reserved. http://www.glarimy.com

OOAD, UML 2.0 & RUPGlarimyAgenda 2009, Glarimy. All rights reserved. Session 1– Fundamentals of Object Orientation– Object Oriented Analysis– Object Oriented Design Session 2– Use Case Analysis– Introduction to UML– Use Case Diagrams– Activity Diagrams– Class Diagrams– Package Diagrams– Component Diagrams– Deployment Diagrams– Sequence Diagrams– State Chart Diagrams Session 3– Rational Unified Process

GlarimyKrishna Mohan Koyya Call me Krishna– Originally from Tadepalligudem inAndhra Pradesh– Have been in Bengaluru since 1998 Held various positions in the ITIndustry– Worked on development of hugesystems Extensive work in the areas of–––– 2009, Glarimy. All rights reserved.Object OrientationDistributed SystemsNetwork Management SystemsJava Technologies

GlarimyAcademics Graduation– B.E. in Electronics & Communication Engineering SRKR Engineering College, Bhimavaram, affiliated to AndhraUniversity, Visakhapatnam 1989-1993 Post Graduation– M.Tech in Computer Science & Technology College of Engineering, Andhra University, Visakhapatnam 1995-1997 Certifications– PMP (Project Management Professional) PMI USA 2005 (Now expired!) Others– Diploma in Business Management (Finance) ICFAI, Hyderabad 2007 2009, Glarimy. All rights reserved.

GlarimyCareer A total of 14 years of experience with the IT IndustrySince July 2008– Technology Consultant & Corporate Trainer– Runs G l a r i m y, online skill development portal June 2007- May 2008– Associate Professor & HOD of Department of IT– Sasi Institute of Technology and Engineering, Tadepalligudem, India Jan 2006 – Dec 2006– Chief Executive Officer– Sudhari IT Solutions India Private Limited, Bangalore, India Dec 2000 – Jan 2006– Software Engineer at Grade 10– Cisco Systems India Private Limited, Bangalore, India Nov 1998 – Dec 2000– Senior Software Engineer– Wipro Technologies, Bangalore, India Others– Dhanya Software for Hewlett-Packard ISO, Bangalore, India in 1998– Ace Software Exports Limited, Rajkot, India in 1997– Neo Software, Visakhapatnam in 1994-1995 2009, Glarimy. All rights reserved.

GlarimyObject Orientation Software– Set of Programs Program is a set of instructions that can be executed by a computer– Code, Documentation, Configuration Software sans any of the above becomes less useful– Automates existing business process It [typically] never creates anything new for a business process Model– Abstracts a thing or a process or an idea Presents only relevant detail, Leaves “extra” details– Always have a context and a purpose No two models may be exactly same Object Orientation– Models existing business processes In terms of objects and their interdependencies 2009, Glarimy. All rights reserved.

GlarimyAbstraction & Encapsulation Abstraction– One of the fundamental principles of Object Orientation Presents only “required” detail about an object A means to deal with the complexity Encapsulation– Wraps the object internals Users look only at the utility– Presents abstraction Outsiders can deal with whole rather than parts Creation, destruction, usage - in terms of whole Objects become reusable Controls access to the internals– Protects the internal details of the object Security, by default– Provides interface for controlled access Public members for every one Private members for no one (except for the object itself) 2009, Glarimy. All rights reserved.

GlarimyClasses Blue Prints– Describes the structure & behavior of objects How an object can be created?What and how an object does something?Who are related to this object?What is visible & accessible to whom?– Do not do anything They are not runtime elements Only objects do, not the blue prints Three Parts– Attributes & Relationships Attributes describe the static internal picture Relationships describe dependencies among objects– Behavior Describes the dynamic picture Class Level Data– Specific to the given class– Data is available even before object is created– Shared among all object of the class 2009, Glarimy. All rights reserved.

GlarimyObjects Represent real world objects/ideas– An object oriented system is just a collection of objects Runtime elements in the system– Represent tangibles as well as intangibles Things, Processes, concepts Instances of classes– Each object belongs to a class All class level data is available to each of the objects– A class can be realized into any number of objects Object level data– Specific to the given instance of the class– Not shared among objects– Data is available only with the specific object 2009, Glarimy. All rights reserved.

GlarimyAttributes & Relations Attributes– Characteristics Describes the inherent structure– Granular Generally very granular in nature May not be described using other structures– Inseparable Every object should have a value for the attribute An object sans the defined attribute is not possible Relations– Among objects Cardinality: One-to-One, One-to-Many, Many-to-One, Many-to-Many Role: Each object has a purpose Navigation: At least one of them ‘knows’ the other– Types of Relations Dependency – “uses” relation, weakestAssociation – “has a” relationAggregation – “owns a” relationComposition – “is part of” relation, strongest– Relation itself can be a class 2009, Glarimy. All rights reserved.

GlarimyBehavior State– Snapshot of set of values of attributes & relations Changes if any of these values change Only object changes states, not class Behavior– The way an object changes its state Class changing state is meaningless– Operation Interface to invoke the behavior State better not be changed directly accessing it– Method An implementation of an operation An operation can be carried in more than one methods - Overloading Message– A means to invoke operation on (another) object Objects passing messages in a system delivers the functionality 2009, Glarimy. All rights reserved.

GlarimyInheritance Deals with hierarchical complexity– Reuses an existing class and extends it further– Specializes the general class It’s a relation of specialization between parent and child It’s an “IS-A” relation– Every child class “IS-A” a parent class, in a way Vice-versa is not true Also not true between two child classes of the same parent Parent Classes & Child Classes– Child inherits everything from the parent Parent can stop one/some/all of its members being inherited All protected members are meant only for the self & children– Child can override parent’s behavior Parent can stop one/some/all of its methods being overridden– Child can extend the parent By adding its own attributes/associations/behavior Parent can stop being extended, of course Multiple Inheritance– A child extends more than one parent 2009, Glarimy. All rights reserved.

GlarimyInterfaces & Polymorphism Classic distinction– What & How “What” deals with “requirement” “How” deals with “implementation” Classes, Objects and Interfaces– Class specifies both “what” & “how”– Object exhibits that specification– Interface specifies only “what”, not “how”. Interface can not do anything, its abstractA class needs to realize this interface by providing “how” specsMore than one class can realize the same interfaceEach class provides different “how” to the same “what” Polymorphism– Users deals with interfaces rather than actual objects Actual object may belong to any of the class implementations– One Interface, many possible implementations Actual behavior depends on the real implementation that is provided The behavior is not known till the implementation is known Different implementations are supplied at different contexts 2009, Glarimy. All rights reserved.

GlarimyAnalysis & Design Understand the big picture– Don’t look for trees, find the forest– Identify the scope and boundaries of the system Generate User Stories– Ask “how” user wants to use the system– Ask “what” user expects from the system– Develop Use Cases Identify the external actors and triggers Identify the expected outcomes Identify the exceptional scenarios. Model the existing business process– Identify all nouns They are candidate objects or attributes or relations– Identify all verbs They are candidate behavior interfaces (operations)– Develop classes Bind the attributes & behavior to appropriate objectsEstablish the relations among the objectsDo not introduce any classes that are not part of the problem statementRemove the classes that are outside of the boundary 2009, Glarimy. All rights reserved.

GlarimyUnified Modeling Language UML– A visual modeling language Offers syntax and semantics– Roots are in software development Applicable to any field– Not a process Used as part of a process Bit of History– Object Orientation and Three Amigos Booch – Booch Methodology Rumbaugh – Object Modeling Technology Jacobson – Objectory– Unified 1994: Started in 1994 with Rational1997: UML 1.0 adoption by Object Management Group (OMG)2005: UML 2.0www.omg.org 2009, Glarimy. All rights reserved.

GlarimyUML 2.0 The Specification– Diagram Interchange Specs For Tool Vendors For importing and exporting diagrams across tools XML representation of elements & their interconnections of a diagram– Infrastructure Foundation for Superstructure Meta model of UML– Superstructure The UML that we use– Object Constraint Language To Define constrains and expressions for elements The Philosophy– Model Driven Architecture Model as an abstraction over programming language To facilitate auto code generation 2009, Glarimy. All rights reserved.

GlarimyUML Artifacts Classifiers– Artifacts that share common properties in UML Classes, objects, methods, activities and etc., Adornments– What you add on top of classifiers Constraints and Stereotypes and etc., Diagrams– Models the system using the artifacts & Adornments Structural & Behavioral Diagrams Profiles– Means to extend the UML Collection of domain specific adornments Notes– Anything that you want to add to improve the clarity 2009, Glarimy. All rights reserved.

GlarimyViews & Diagrams Classic 4 1 System Views– Not part of UML– Design Views Classes, Patterns and etc– Deployment Views Configuration, Installation and etc.,– Implementation Views Components, Resources, Files and etc.,– Process Views Concurrency, Performance and etc.,– And Use Case View Overall what is seen by the users UML 2.0 Diagrams– Structural Class Diagrams, Object DiagramsComposite Structure Diagrams, Package Diagrams, Component DiagramsDeployment Diagrams– Behavioral Use Case Diagrams, Activity DiagramsState Machine Diagrams, Sequence Diagrams, Communication DiagramsTime Diagrams, Interaction Overview Diagrams 2009, Glarimy. All rights reserved.

GlarimyUse Case Analysis Use Case Analysis– An approach to requirement analysis Customer & Analyst participate Comes out with User Stories and Use Case Diagrams– Identifies system boundaries Finalizes the requirement scope– Focus is on “what needs to be delivered” Not concerned about “How the functionality will be achieved” Deliverables– Use Cases Feature of the system from external point of view Helps in putting together a requirements traceability matrix– Use case Diagrams Helps in putting together the requirements specifications 2009, Glarimy. All rights reserved.

GlarimyUse Case Diagrams Use Case Diagrams– One of the UML 2.0 Behavioral Diagram Collection of Use Cases, Actors and Subject Subject– Whose functionality is being analyzed Typically of a process/subsystem/component/class and etc Actor– Uses the use case or receives the use case results External to the subject, not part of it May not map to real users, but to their roles Can inherit other actors Use Case– A feature of the system from the external user point of view Must be initiated by an actor Can extend / include other use cases– When it is completed Desired functionality must have been performed Or an error has been thrown Use can be repeated 2009, Glarimy. All rights reserved.

GlarimyActivity Diagrams Activity Diagrams– Model activities of a classifier Classifier can be a class, use case, component– Activities are made up of actions connected with edges– Rectangle with rounded corners with a name Actions–––––Data manipulation/processing unit of activity diagramClassifier provides the contextAccesses attributes and relations of the classifier.Rectangle with rounded cornerCan have pseudo code within them Constraints– precondition – postcondition – Notes also can be supplied 2009, Glarimy. All rights reserved.

GlarimyActivity Diagrams Tokens– Data output from an action to another action– Data input to an action from other action Input parameter sets– Provides input parameters to whole activity diagram Control Flows– No tokens flows from an action to other action; Simple edges Object flows– Tokens flows from one action to another action– {weight N} N instances of ip token are required to start the activity N instances of op tokens are required to start the next activity Stereotypes–––– selection transformation multicast multireceive 2009, Glarimy. All rights reserved.

GlarimyActivity Diagrams Parameter nodes– Simple input and output Object nodes–––––Complex dataInput PinOutput PinException pin - with triangleValue pins - with const value written at the pin Initial node - starts the activity Final node - ends the activity Decision & Merge nodes––––Selects (only) one flowGuard condition resolves to Boolean valueNon intrusive data as decissionInput Merge join several flows into one flow Fork & Join nodes– Fork creates several concurrent flows– Join joins concurrent flows into one flow– Join specification 2009, Glarimy. All rights reserved.

GlarimyActivity Diagrams Connectors– Splits diagram into smaller pieces Activity partitions– Activity Ownership Swim lanes to separate the ownership Underlined class names on the activity– Exception handling activities With lightening edges Other nodes– Stream Nodes Output can be delivered while input is still being received– Data store Nodes Represents data stores Loops 2009, Glarimy. All rights reserved.

GlarimyClass Diagrams Class diagrams– Invariably, most popular static UML diagram– Presents classes and their relations, statically Class– Three compartments: name, attributes, operations: Attributes– Primitive types (Inline attributes)– References (Relationships) Inline attribute– visibility /name :type multiplicity default {property strings &constraints} visibility: , -, #, multiplicity: [lower.upper], [5], [1.5], [*], nothing is one. Derived Attributes– Prepend with /– Computed based on other parts of the class, typically read-only 2009, Glarimy. All rights reserved.

GlarimyClass Diagrams Attribute Constraints– Natural language– OCL {[name]:expression} {ordered} {unique} Collections––––Order Set- OUSequence: OSet: UBag: Static Attributes– underline 2009, Glarimy. All rights reserved.

GlarimyClass Diagrams Operations– To specify how to invoke behavior– op: visibility name (params): return-type {properties} params: direction param: type [multiplicity] default{properties}– direction : in, out, inout, return– properties: {precondition: postcondition: }––––Query operations: doesn't change the stateBody conditions: can be replaced by subclassExceptionsStatic: underline Method is an implementation of operation Operations without implementation are abstract 2009, Glarimy. All rights reserved.

GlarimyClass Diagrams Relations– Dependency: weekest, uses, dashed line– Association: has-a, solid line, navigation (right, cross symbols), namethat will not get into code, multiplicity (shared)– Aggregation: owns-a, solid line with empty diamond on owner, name,multiplicity, navigability (shared with others)– Composition: is-part-of, not shared, all others, filled-diamond on owner Association class– Named association as a class– Linked classes know each other through it– Dashed line from the association link to the association class. Association qualifier– Like membership-id in the relation between member & club. Generalization– is-a,– Triangle on parent– Abstract classes are realized dashed inheritance 2009, Glarimy. All rights reserved.

GlarimyClass Diagrams Abstract Class– Class name is in italics– Some operations are abstract– Can't be instantiated Interface– pure abstract– Need not to have operations Templates– Dashed rectangle on top-right corner of template class– Comma separated element types in the dashed rect To specify types 2009, Glarimy. All rights reserved.

GlarimyPackage Diagrams Packages– Grouping elements– Packages themselves can be packaged Visibility– Element names with are public to the package– Element names with – are private to the package– Imported elements are public in importing package import – Accessed elements are private in importing package access 2009, Glarimy. All rights reserved.

GlarimyComponent Diagrams Component––––––Is a sub-systemInternals are hiddenShows "provided interfaces“Shows functionalityShows "required interfaces“Shows what is required from the user Component Diagrams– Rectangle– component or component icon on top-right corner Black-box– Three compartments: component name, provided interface and required interfaces artifacts White-box– Shows component structure 2009, Glarimy. All rights reserved.

GlarimyDeployment Diagrams Deployment Diagrams– Maps software pieces (artifacts) to hardware (nodes)– Nodes communicate with each other along the communication paths Artifact–––– Rectangle with dog-ear paper on top-right, name in the centerCan have properties/operations (configuration)Instance is underlined artifactManifests (implements) other componentNodes– Hardware or containers Execution Environment–––––Software container node like BrowserStereotypes to be provided by profile developers like OS , RDBMS etcMay have a comportment showing the services Device are hardware, can be nestedCommunication Paths are undirected solid lines between nodes, what passes(PDU) is not specified.– Deployment is associating nodes with artifacts– Deployment specs define properties to specify how the deployment shouldhappen like web.xml. 2009, Glarimy. All rights reserved.

GlarimySequence Diagrams Sequence Diagrams––––LifelinesParticipants create , destroy , local variables, self , filled arrowsMessage: attribute signal/opName(args):return value Creation & Deletion– Object creation using arrowed dashed line with create – Object deletion using destroy Messages––––Asynchronous message as open arrowReturn values using arrowed dashed lineFound message from unknown sender using filled circleLost message to unknown destination using filled circle Execution occurrences– Rectangles on the lifeline– Shows object as busy 2009, Glarimy. All rights reserved.

GlarimySequence Diagrams Interaction Fragments– Parts in the sequence diagram of special interest– Fragments are shown as combined fragment with interactionoperator Interaction Operators––––––alt ernative: [guard] and [else]opt: [guard]break: [guard] then {., return}par allelcritical regionloop Decomposition– Replace lifelines with REF other diagram Continuations– Placeholders in sequence diagram to put your ownimplementation 2009, Glarimy. All rights reserved.

GlarimyState Chart Diagrams State chart Diagrams– State changes of a class/component– Note on the class/component to link to its state chart diagram States– Is a moment in the behavior of classifier– can represent static (waiting) or dynamic (doing) situation State Representation– Rectangle with rounded corners with Name Internal activities Internal transitions Transition– Transition: event {att list} [guard]/transition– Upon entering state becomes active– Upon leaving it becomes inactive Types– Simple– Composite– Submachine states 2009, Glarimy. All rights reserved.

GlarimyLeave Process SystemOrganization x wants to automate its leave process. All the employees are eligible for paid leaves andthe number depends on their designation. Each employee have to request the manager for leaveexcept the CEO for whom there is no manager. The request should have details like start date and enddate, number of days, reason for leave and contact number on leave. The manager can accept orreject the leave. However, the immediate manager can grant leave only if the sufficient leave balanceisavailable for the employee. Otherwise, the manager will have to escalate it to his/her mamanger. Thatmeans, negative leave balance is allowed but can not be granted by the immediate manager. Noleaves would be carried forward to the next year.This application should be a web based application and all the employees must be authenticated. Theemployee data base is already available which have the details like name, employee id, designation,employee id of the immediate manager, maximum leaves per year, leaves utilized and etc., Employeesmust be able to raise the leave request, view the status of the request, update the request and cancelthe request. The manager must be able to view the leave record of all his/her team members, view theleave requests pending, cancel/accept/escalate a the request and view the leave history of anemployee. Reports can also be provided. 2009, Glarimy. All rights reserved.

GlarimyRational Unified Process What is RUP A software engineering processA process product from Rational (now IBM)A way to enhance team productivityA way to replace paper documentation with modelsA guideline to effectively using UMLA configurable processA repository of best practices The 6 Best Practices Develop software iterativelyManage requirementsUse component-based architectureVisually model softwareVerify software qualityControl changes to software 2009, Glarimy. All rights reserved.

GlarimyRUP: Inception Phase– A vision document– A general vision of the core requirements– Key features– Main constraints– A initial use-case model– 10% -20% complete– An initial project glossary– An initial business case– Business context– Success criteria– Financial forecast.– An initial risk assessment– A project plan– Phases and iterations– One or several prototypes– Milestone: Lifecycle Objective 2009, Glarimy. All rights reserved.

GlarimyRUP: Elaboration– A use-case model– Around 80% complete– Actors for all use cases– Description for most of the use cases– Supplementary requirements––––– Non functional requirements– Other requirements– Not associated with a specific use caseA Software Architecture DescriptionAn executable architectural prototypeA revised risk list and a revised business caseA development plan for the overall project– Coarse-grained project plan– Iterations with evaluation criteria– Milestone: Lifecycle Architecture 2009, Glarimy. All rights reserved.

GlarimyRUP: Construction & Transition– Construction––––The software product integrated on the adequate platformsThe user manualsA description of the current release.Milestone: Initial Operational Capability– Transition– Beta testing– Validate the new system against user expectations– Parallel operation with a legacy system– Pilot run– Conversion of operational databases– Training of users and maintainers– Roll-out the product– To the marketing– To the distribution– To the sales teams– Milestone: Product Release 2009, Glarimy. All rights reserved.

GlarimyFinal WordsOOADA way to comprehend the systemA way to design an automated solutionUMLA way to communicate the system orsolutionRUPA process to effectively use the UML 2009, Glarimy. All rights reserved.

GlarimyFor Technical Querieskrishna@glarimy.comFAQ, Tutorials, Presentations,Samples, Quizhttp://www.glarimy.comwww.glarimy.comThank YouFor Appointments091-9731 4231 66 2009,2008, Glarimy. All rights reserved.

-Not a process Used as part of a process Bit of History -Object Orientation and Three Amigos Booch - Booch Methodology Rumbaugh - Object Modeling Technology Jacobson - Objectory -Unified 1994: Started in 1994 with Rational 1997: UML 1.0 adoption by Object Management Group (OMG) 2005: UML 2.0 www .