Scribd Logo
Upload

Welcome to Scribd!

  • Lecture 3

    Uploaded by

    Zain Chishti
    13 views9 pages
    vx

    Original Title

    lecture_3

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    vx

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF or read online from Scribd
    Flag for inappropriate content
    13 views9 pages

    Lecture 3

    Uploaded by

    Zain Chishti
    vx

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF or read online from Scribd
    Flag for inappropriate content
    of 9
    LECTURE NO: 3 What is the Rational Unified Process? ‘The Rational Unified Process is a process product, developed and maintined by Rational Sofware The development feam for the Rational Unified Process is working closely with customers, partner, Rationals product groups as well as Rationals consultant organization, to censure thatthe process i contimonsly updated and improved pon to reflect recent experiences ‘and evolving ané proven best practices. The Rational Unified Process enhances team productivity, by providing every team member with easy access to a knowledge base with ‘gusdelines, templates and too! mestors for all ential development activities. By having all team amemiers accessing the same knowledge base, no mutter if you work with requirements, design, test project management, or configuration management, we enste that all team members share a commos language, process and view of how to develop softvare. The Rational Unified Process activites create and maintain models. Rather than focusing on the production of large amount of paper decuments, the Unified Process emphasizes the development and maintenance of models— semantically rch representations of the software system under development. ‘The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language (UML). The UML is an indusry-standard language that allows us to clearly commmuicate requizements, architectures and designs. The UML was originally created by Rational Software, and is now maintained ty the standards organization Object Management Group (OMG). ‘The Rational Unified Process is supported by tools, which automate large pasts of the process. ‘They are used to create and maintain the various atifactsmodels in particula—of the software engineering process: visual modeling, programming. testing, etc. They are iavalwable in supporting all the bookkeeping associated with the change management as well as the configwation management that accompanies each iteration The Rational Unified Process is a configurable process. No single process is suitable for all software development. The Unified Process fits small development teams as well as large development orgasizations. The Unified Process is founded on a simple and clear process architecture that provides commonality across a family of processes. Yet, it can be varied to accommodate different situations. It contains a Development Kit, providing support for configuring the process to suit the needs of a given ‘organization. The Rational Unified Process captures many of the test practices in modem software development in 2 form that ic suitable for a wide range of projects and organizations ‘The fundamental practices are discussed in next section Static Structure of the Process. A process describes veho i doing wit, how, and when. The Rational Unified Process is ‘represented using four pomary modeling elements: Werkers the who’ w > Activities, the how? > Axtfacts, the “wat > ‘Workdlows, the ‘when’ Activities, Artifacts, and Workers Worker A workor defines the behavior and responsbilities of an individual, or a group of indiviguale ‘working together as a team. You could regard a worker as a "hat" aa individual can wear in the project One individual may wear many different hats. This is an importaat distinction because it is natural to think of a worker as the individual or team itself but in the Unified Process the worker is more the role defining how the individuals should cany out the work. The responsibilities we assign to a worker include both to perfomn a certain set of activites as well as being owner ofa set of artifacts. @ Resource worker acwies [> Pau —— = Besioner tie Desion vy > Workflows: Astifacts may take various shapes or forms: A model, such as the Use-Case Model or the Design Model ‘A model element, ie. an element within a model, such as a class, a use case ora subsystem ‘A document, such as Business Case or Software Architecture Document Source code A mere enumeration ofall workers activities and artifacts does not quite constitute a process, We ‘need away to describe meaningful sequences of activities that produce some valuable result, and to show interactions between workers. A workflow is a sequence of activites that produces a result of observable value i >>> SS s “bb Example of workflow Note that it is nct always possible or practical to represent all of the dependencies between activities. Offen two activities are more tightly interwoven than shown, especially when they involve the same worker or the same individual. People are sot machines, and the workflow ‘cannot be interpreted Literally as a program for peuple, to be followed exactly and mechanically Software Design Components ‘When we design the design ofthe software, we have fo deal wth three types of components that mike wp the design ofthe softwar, thee componsats areas fllon: i. Principle Criteria Techniques i. Principle This component of the software design has mmliple sub-components and out of these subcomponents we have to decide and design the problem under discussion depending upon the nature of the problem. Design Principles — A Taxonomy bwmfeuen eaten rzortt / verte growing a nea ee a. Abstraction As seen in the diagram above, abstraction is the root of the design principle so before actually ssarting discussion let us try to find its practical meaning frst using an example. Myth about Abstraction > Ons task is to design a management information system for a hospital; it should include patient management, doctor's management, laboratory management inventory of ‘equipment and medicines. i, Programmers Approach: Let us first discuss the approach which will be followed by a typical programmer. ‘Typicelly programmer will stat by saying and thinking about the technology spect for ‘implementation without going into the details of design companent of the system This will ‘eagage the programmer with technology aspect earlier in the design cycle where there will be a sot needed discussion between technological implications on to be designed software design!! ii, System Architect Approach, “The approach of System architect would be to forget the technology, fst understand what todo in detail then generste Requirement Specification (RS) aud from RS generate Fusctioual specification FS) and design document (DD) ~ This is “Abstraction” Abstraction Defined: “A view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information” IEEE Standard 610.12-1990 ‘The abstraction notion is central to understanding the representational requirements of Design activities. Put very simply, the use of abstractions during design gives the designer freedom to ignore certain details, forthe time being, and to determine or design the "big picture" aspects of his design. The use of abstractions allows the designer to fely shift is focus ffom one patt of the

    You might also like