This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• 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
• A total of 14 years of experience with the IT Industry• Since 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
• 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
– 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
– 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 abstract• A class needs to realize this interface by providing “how” specs• More than one class can realize the same interface• Each 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
– 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 objects• Establish the relations among the objects• Do not introduce any classes that are not part of the problem statement• Remove the classes that are outside of the boundary
• 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
– 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
– Behavioral• Use Case Diagrams, Activity Diagrams• State Machine Diagrams, Sequence Diagrams, Communication Diagrams• Time Diagrams, Interaction Overview 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
– 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 diagram– Classifier provides the context– Accesses attributes and relations of the classifier.– Rectangle with rounded corner – Can have pseudo code within them
• Constraints– <<precondition>>– <<postcondition>>– Notes also can be supplied
that 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
– 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
– Is a sub-system– Internals are hidden– Shows "provided interfaces“– Shows functionality– Shows "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>>
– 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 center– Can have properties/operations (configuration)– Instance is underlined artifact– Manifests (implements) other component
• Nodes– Hardware or containers
• Execution Environment– Software container node like Browser– Stereotypes to be provided by profile developers like <<OS>>, <<RDBMS>> etc– May have a comportment showing the <<services>>– <<Device>> are hardware, can be nested– Communication 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 should
– Lifelines– Participants– <<create>>, <<destroy>>, local variables, <<self>>, filled arrows– Message:= 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 arrow– Return values using arrowed dashed line– Found message from unknown sender using filled circle– Lost message to unknown destination using filled circle
• Execution occurrences– Rectangles on the lifeline– Shows object as busy
• 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
• A software engineering process• A process product from Rational (now IBM)• A way to enhance team productivity• A way to replace paper documentation with models• A guideline to effectively using UML• A configurable process• A repository of best practices
• The 6 Best Practices• Develop software iteratively• Manage requirements• Use component-based architecture• Visually model software• Verify software quality• Control changes to software
– 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 case– A Software Architecture Description– An executable architectural prototype– A revised risk list and a revised business case– A development plan for the overall project
– Coarse-grained project plan– Iterations with evaluation criteria
– The software product integrated on the adequate platforms– The user manuals– A 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