Study for the day when you don't have to worry about price tags.
--Your friends at LectureNotes

Note for UML and Design Pattern - UDP by Anudeep Sunny

  • UML and Design Pattern - UDP
  • Note
  • Computer Science Engineering
  • B.Tech
  • 6 Topics
  • 1 Offline Downloads
  • Uploaded 11 months ago
0 User(s)
Download PDFOrder Printed Copy

Share it with your friends

Leave your Comments

Text from page-2

Activity Roles have activities that define the work they perform. An activity is something that a role does that provides a meaningful result in the context of the project. An activity is a unit of work that an individual playing the described role might be asked to perform. The activity has a very clear purpose, normally expressed in terms of creating or updating some artifacts,like a model, a class, a plan. Each and every activity is assigned for a specific role. The granularity of an activity is basically a few hours to a few days, it generally involves one role, and affects one or only a small number of the artifacts. An activity must be used as an element of planning and progress.If it is too small, then it will be neglected, and if it is too large, then the progress would have to be expressed in terms of an activity’s parts. Activities should be repeated number of times on same artifact, especially when going from one of the iteration to another, refining and expanding the system, by means of the same role, but not necessarily of the same individual. Steps Activities are broken down into several steps. Steps fall into the three main categories: 2

Text from page-3

• Thinking steps: is a step where the individual performing the role understands the nature of task,gathers and then examines the input artifacts, and formulates the outcome. • Performing steps: is a step where the individual performing the role creates or updates certain artifacts. • Reviewing steps: is a step where the individual performing the role inspects the results against some criteria. It is not necessary to perform these steps each time an activity is invoked, and so they can even be expressed in the form of alternate flows. Example of steps: The Activity: Find use cases and actors decomposes into the following steps: Step1. Find actors Step2. Find use cases Step3. Describe how actors and use cases interact Step4. Package use-cases and actors Step5. Present the use-case model in use-case diagrams Step6. Develop a survey of the use-case model Step7. Evaluate your results. The finding part [steps 1 to 3] needs some thinking.The performing part [steps 4 to 6] involves capturing the result in use-case model; the reviewing part [step 7] is the one where the individual performing the role evaluates the result to assess the completeness, robustness, intelligibility, or other qualities. Work Guideline Activities can have associated Work Guidelines, that present techniques and practical advice which is useful to the role performing the activity. 3

Text from page-4

Workflow A mere enumeration of all the roles, activities and artifacts do not constitute a process.we require a way to describe meaningful sequences of activities which produce some valuable result, and also to show interactions between the roles. A workflow is a sequence of activities that produces a result of observable value. In UML terms, a workflow may be expressed as a sequence diagram, a collaboration diagram, or even as an activity diagram. We use a form of activity diagrams in the RUP. For each and every discipline, an activity diagram is presented. This diagram shows the workflow, that is expressed in terms of the workflow details.The great difficulties of describing the process is that there are number of ways in order to organize the set of activities into the workflows. RUP is organized using the following: • Disciplines • Workflow details Workflow Detail For most of the disciplines, you may also find the workflow detail diagrams,that shows the group of activities which are often performed "together". 4

Text from page-5

These diagrams show the roles involved, input and output artifacts and also the activities performed. The workflow detail diagrams are there for the following reasons: The activities of a workflow are neither done all at once, nor performed in sequence. The workflow detail diagram says how often it works in workshops or in team meetings when performing a workflow. Typically we work in parallel on more than one activity and look at more than one artifact while doing that. There are various workflow detail diagrams for a particular discipline. It becomes too complex in order to show the input and the output artifacts for all the activities of a discipline in one diagram. The workflow detail diagram allows you to show the activities and artifacts together, for one part of a workflow at a time. The disciplines are not completely independent of one another. For example, integration occurs in both implementation and also in test disciplines, and in reality you never really do one without other. The workflow detail diagram may show a group of activities and artifacts in the discipline, together along with closely related activities in another discipline. 5

Lecture Notes