Tarkvara kokkuvõte inglise keeles (0)

1 Hindamata
Punktid

Esitatud küsimused

  • Kus vajatakseCMMi ?
 
Säutsu twitteris
1. OBJECT -ORIENTED PARADIGM
The Model
•The model defines an abstract view to the problem. This implies that the model focuses only on problem related stuff and that you try to define properties of the problem.
These properties include :
  • •the data which are affected and
  • •the operations which are identified by the problem.
    Object-oriented Paradigm
    •Everything is an object
    •A program is a bunch of objects telling each other what to do by sending messages
    •Each object has its own memory made up of other objects
    •Every object has a type
    •All objects of a particular type can receive the same messages
    Domain Model
    •A domain model does not represent the entire domain as it is in the real world. It includes only the concepts that are needed to support the application .
    Object
    •Is a partitioned area of memory where object code is stored
    •The area of memory is protected
    •This code can function relatively independently of other objects
    •Can be used by many parts of one program or by parts of many programs
    Message Passing
    •The mechanism by which objects communicate
    •The object can accept or reject the message
    •From outside the object it appears to be active data
    •From inside the object the data is passive --the message tells the object what to do with the data
    Classes
    •A very basic concept in OOP
    •It is a template for creating actual, functioning objects of a given type
    •In some cases a class is an object
    •simile
    –A class is a blueprint or DNA for creating a cow. But
    – it is the actual cow that produces milk , not the cow class
    –All cows are made from the cow class
    Methods
    •Messages = Requests in avenue
    •A request is just that: a requestfor an object to do something .
    •Something ranges from changing properties (like gender) to doing something like copying itself or printing.
    •Properties are “things”in the object that can be changed.
    Instansion
    •A class is instantiated when it is used to stamp out one or more objects of its type
    •Objects that are created from a given class are called instances of that class
    Encapsulation means that the properties and methods of an object are not directly accessible to the outside world.
    Inheritance is the ability to create new classes based on an existing class. The new class inherits all the properties and methods and events of the base class, and can be customized with additional properties and methods.
    Polymorphism is the ability of different classes to define properties or methods with the same name. Polymorphism is essential to object-oriented programming because it allows you to call methods with the same names, no matter what type of object is in use at the moment.
    2. COMPONENT TECHNOLOGY – THE PROBLEM
    The Problem
    Today , anything and anyone must be net-enabled.
    •Automated business processes , products , and software systems need to evolve in „e-Time“.
    •Everything must be changeable, extensible, adaptable.
    Quality is an important issue .
    Architectural consequences of these requirements :
    •Software should not be designed as monolithic unit but partitioned into composableservices that can be spontaneously connected and orchestrated by business/technical processes (component-based software).
    •„Software entropy“should be maximized: loosely coupling between peers,decentralized information access , reflective approaches (Just-in-Time Integration).
    •Software must be e-enabled.
    Application Partioning
    Solutions consist of collections of components .
    •Components are divided into multiple packages.
    •Packages can work with each other across a network through ObjectRequestBroker(ORB).
    •This application partitioning is transparent to the component developer .
    3. COM Principles:
    Rigorous Encapsulation: - no leakage of implementation details; – All object manipulation through strict interfaces.
    Polymorphism: – via multiple interfaces per class; – “Discoverable”: Query Interface
    COM Model – how the techogy is used.
    COM ORB = COM Runtime – how is it implemented.
    COM is efficianet and scalable: 28 bytes headers; keep-alive messages.
    ActiveX: marketing name for a set of technologies and services , all based on COM(model,orb)
    Active components - controls: COM-component with designed time, optimized for download and execute; self-registering; support in multiple languages.
    OLE:1.0 – object and container (server/ client ); object application runs in own window. 2.0visual editing,COM based, controls = *.ocx files.
    .NET: Process : source code->compiler-> metadata ->CLR-> result .
    CLR: .Net execution environment-execution management ; provide services.
    Managed Code provides: cross-laguage integration; auto memory services; self- described objects; compile once -run everywhere.
    Metadata: describe components, objects and execution conditions ; provide garbage collection .
    MSIL=Microsoft Intermediate language (between compiler and JIT)
    JIT=Just in Time compiling. Part of data compile only in run-time when it is needed.Loader creates stub for every method .After,querys go to mashinecode.Convert verification-safe code.
    Assembly is a partially compiled code library for use in deployment , versioning and security . Two types , process assemblies (EXE) and library assemblies (DLL). Process assembly use classes from library assemblies.
    Summary:assembly=component;MS computing distributes among servers and clients via .Net assemblies; .NET more versatile than DCOM+; Asseblies interoperable among MS languages.
    4. Relationships
    I Association (Models a semantic connection among classes)
    – Aggregation (A special form of association that models a whole -part relationship between an aggregate (the whole) and its parts)
    Composition (A form of aggregation with strong ownership and coincident lifetimes)
    II Dependency
    III Generalization
    IV Realization
    I Association: Multiplicity and Navigation
    • Multiplicity defines how many objects participate in a relationships
    – The number of instances of one class related to ONE instance of the other class
    – Specified for each end of the association
    • Associations and aggregations are bi-directional by default, but it is often desirable to restrict navigation to one direction
    – If navigation is restricted, an arrowhead is added to indicate the direction of the navigation
    Association: Multiplicity
    • Unspecified
    • Exactly one 1
    Zero or more (many, unlimited) 0..*
    • One or more 1..*
    • Zero or one 0..1
    • Specified range 3..7
    • Multiple, disjoint ranges 2, 5..7
    II Relationships: Dependency
    • A relationship between two model elements where a change in one may cause a change in the other
    • Non-structural, “using” relationship
    III Relationships: Generalization
    • A relationship among classes where one class shares the structure and/or behavior of one or more classes
    • Defines a hierarchy of abstractions in which a subclass inherits from one or more superclasses
    Single inheritance
    – Multiple inheritance
    • Generalization is an “is-a-kind of” relationship
    What Gets Inherited?
    • A subclass inherits its parent ’s attributes, operations, and relationships
    • A subclass may:
    – Add additional attributes, operations, relationships
    – Redefine inherited operations (use caution!)
    • Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy
    IV Relationships: Realization
    • One classifier serves as the contract that the other classifier agrees to carry out
    Found between:
    – Interfaces and the classifiers that realize them
    – Use cases and the collaborations that realize them
    5. Unified Modeling Language
    Use Case Analysis is a technique to capture business process from user ’s perspective.
    What is the UML?
    • UML stands for Unified Modeling Language
    • The UML combines the best of the best from
    – Data Modeling concepts (Entity Relationship Diagrams )
    – Business Modeling (work flow)
    – Object Modeling
    – Component Modeling
    • The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software- intensive system
    • It can be used with all processes, throughout the development life cycle , and across different implementation technologies
    UML 2.0-is avisual modeling lang.,describes the specification and design of a soft intensive system via visual models
    UML2.0 history: fragmentation (the method wars), unification (booch, rumbaugh, Jacobson), standardization (UML1.1) ,industrialization. =>1.3.01.4.1.5 2.0
    AN Architectural representation: logical ,implementation, process, deployment views
    Use Case Diagramm shows all the ways of using the system; classifiers can now own use cases.
    Associated Diagrams: activity d.-can be used to model interaction between scenarios.
    Activity Diagram :
    Focus on flow of activities involved in a process.
    Significant changes from UML1.X-now address real time flow,incorporated Petri Net concepts
    -decompose activity into multiple actions
    -activity parameters and pins
    Useful because they focus on workflow-don’t have to reference a prticular object so ideal to map complex alternarive flows in a use case.
    Visual map of a set of activities and possible transitions between them –activities by one or more operations.
    Activity Modeling
    •The sequence and conditions for coordinating other behaviors
    • … using secondary constructs to show which classifiers are responsible for those behaviors.
    • Focus is on what tasks need to be done , in what order , rather than who/what performs each task
    Interfaces UML1.X supports only in 1 direction, UML2.0-bidirectional interface.
    Package Diagrams-organises the model,dependency indicates a usage relationship between contents of the packages,use it to model the high-level organization of the system,indicate visibility on owned elements,import from packages,supports package merge.
    Ports -NEW. -defines as interaction point on a classifier (between it and its enviroment)
    Composition 2.0 PORTS=public parts.
    Composite Structure Diagram. UML 1.x only had composition to model internal structure, UML2.0 introduces this d. to model “hidden”detail.
    UML – Modeling Techniques
    • Business rules
    • Change cases
    • Class responsibility collaborator (CRC) models
    • Constraints
    • Essential use case models
    • Essential user interface prototypes
    • Persistence/data models
    • Technical requirements
    • UML activity diagrams
    • UML class models
    • UML collaboration diagrams
    • UML component diagrams
    • UML deployment diagrams
    • UML sequence diagrams
    • UML state chart diagrams
    • UML use case models
    • User interface flow diagrams
    • User interface prototypes
    UML põhidiagrammid :
    • Staatika diagrammid
    • Klassidiagramm
    Use Case diagramm
    • Dünaamika diagrammid
    – Suhtlusdiagrammid
    • Jadadiagramm (sequence diagram)
    • Koostöödiagramm (collaboration diagram)
    Elutsükli dikagrammid
    • Seisundidiagramm (state diagram)
    • Tegevusdiagramm (activity diagram)
    • Realisatsiooni diagrammid
    • Komponendidiagramm (component diagram)
    • Rakendusdiagramm (deployment diagram)
    UML Concepts
    • The UML may be used to:
    – Display the boundary of a system & its major functions using use cases and actors
    – Illustrate use case realizations with interaction diagrams
    – Represent a static structure of a system using class diagrams
    – Model the behavior of objects with state transition diagrams
    – Reveal the physical implementation architecture with component & deployment diagrams
    – Extend your functionality with stereotypes
    Object Orientation:
    - Encapsulation
    - Abstraction
    - Hierarchy
    - Modularity
    Class Compartments
    • A class is comprised of three sections
    – The first section contains the class name
    – The second section shows the structure (attributes)
    • The third section shows the behavior (operations)

    The Relationship Between Classes and Objects
    • A class is an abstract definition of an object
    – It defines the structure and behavior of each object in the class
    – It serves as a template for creating objects
    • Objects are grouped into classes
    Polymorphism - The ability to hide many different implementations behind a single interface
    What is an Interface?
    • Interfaces formalize polymorphism
    • Interfaces support “plug-and-play” architectures
    What is a Component?
    • A non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture
    • A component may be
    – A source code component
    – A run time components or
    – An executable component
    What is a Package?
    • A package is a general
  • 80% sisust ei kuvatud. Kogu dokumendi sisu näed kui laed faili alla
    Vasakule Paremale
    Tarkvara kokkuvõte inglise keeles #1 Tarkvara kokkuvõte inglise keeles #2 Tarkvara kokkuvõte inglise keeles #3 Tarkvara kokkuvõte inglise keeles #4 Tarkvara kokkuvõte inglise keeles #5 Tarkvara kokkuvõte inglise keeles #6 Tarkvara kokkuvõte inglise keeles #7 Tarkvara kokkuvõte inglise keeles #8 Tarkvara kokkuvõte inglise keeles #9 Tarkvara kokkuvõte inglise keeles #10 Tarkvara kokkuvõte inglise keeles #11 Tarkvara kokkuvõte inglise keeles #12 Tarkvara kokkuvõte inglise keeles #13 Tarkvara kokkuvõte inglise keeles #14 Tarkvara kokkuvõte inglise keeles #15 Tarkvara kokkuvõte inglise keeles #16 Tarkvara kokkuvõte inglise keeles #17 Tarkvara kokkuvõte inglise keeles #18
    Punktid 100 punkti Autor soovib selle materjali allalaadimise eest saada 100 punkti.
    Leheküljed ~ 18 lehte Lehekülgede arv dokumendis
    Aeg2015-04-08 Kuupäev, millal dokument üles laeti
    Allalaadimisi 11 laadimist Kokku alla laetud
    Kommentaarid 0 arvamust Teiste kasutajate poolt lisatud kommentaarid
    Autor keeksirull Õppematerjali autor

    Mõisted

    Sisukord

    • OBJECT-ORIENTED PARADIGM
    • The Model
    • Object-oriented Paradigm
    • Domain
    • Model
    • Object
    • Message Passing
    • Classes
    • Methods
    • Instansion
    • Encapsulation
    • Inheritance
    • Polymorphism
    • COMPONENT TECHNOLOGY – THE PROBLEM
    • The Problem
    • Architectural consequences of these requirements
    • Application Partioning
    • COM Principles
    • Relationships
    • I Association: Multiplicity and Navigation
    • Association: Multiplicity
    • II Relationships: Dependency
    • III Relationships: Generalization
    • What Gets Inherited?
    • Relationships: Realization
    • UNIFIED MODELING LANGUAGE
    • UML – Modeling Techniques
    • UML põhidiagrammid
    • UML Concepts
    • Object Orientation
    • Class Compartments
    • The Relationship Between Classes and Objects
    • Polymorphism
    • What is an Interface?
    • What is a Component?
    • What is a Subsystem?
    • Subsystems and Components
    • WATERFALL MODEL
    • Why a Pure Waterfall Process is Usually Not Practical
    • Waterfall Process Assumptions
    • Waterfall Process Limitations
    • Test-Action-Cycleas optimisationcycle
    • CAPABILITY MATURITY MODEL (CMM)
    • Total Quality Management
    • Põhimõisted
    • Immature versus Mature Software Organizations
    • The Five Levels of Software Process Maturity
    • Organisatsiooni küpsustastmed
    • Kus vajatakseCMMi?
    • The OPEN
    • Strengths of the OPEN Process
    • The OPEN Process serious drawback
    • RUP—
    • THE APPROACH
    • The Spirit of the RUP – Essential Principles
    • The Iterative Approach
    • The RUP—A Well-Defined Software Engineering Process
    • Extreme Programming Practices
    • Extreme Programming - Four Variables
    • Extreme Programming Explained
    • Extreme Programming - Estimating User Stories
    • Feature-Driven Development (FDD)
    • FDD Best Practices
    • Scrum
    • Scrum
    • STRUCTURES
    • Rational Software
    • What Is the Rational Unified Process?
    • Principles and best practices
    • -23. THE DYNAMIC STRUCTURE OF THE RATIONAL UNIFIED PROCESS
    • The Dynamic Structure of the Rational Unified Process
    • Inception (
    • Inception Phase
    • Software Requirements (
    • Elaboration
    • Elaboration (
    • Phase
    • Construction
    • Construction Phase
    • Transition
    • Transition Phase
    • Enterprise Unified Process
    • 
    • Open Unified Process (OpenUP)
    • CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
    • -30. CMMI Representations
    • The Continuous Representation
    • The Staged Representation
    • Capability Profile
    • Crystal Clear
    • Agile SW Delivery
    • Software Quality
    • Software Quality Factors
    • Acceptance Testing
    • Configuration Management

    Teemad

    • OBJECT-ORIENTED PARADIGM
    • properties
    • data
    • operations
    • request
    • COMPONENT TECHNOLOGY – THE PROBLEM
    • Architectural consequences of these requirements
    • component-based software
    • Just-in-Time Integration
    • e-enabled
    • ObjectRequestBroker(ORB)
    • COM Principles
    • ActiveX
    • Active components
    • CLR
    • Assembly
    • Relationships
    • UNIFIED MODELING LANGUAGE
    • UML 2.0
    • UML2.0 history
    • AN Architectural representation
    • Activity Diagram
    • Activity Modeling
    • Interfaces UML1.X supports only in 1 direction, UML2.0-bidirectional interface
    • Package Diagrams
    • Ports-NEW
    • Composition 2.0 PORTS=public parts
    • Composite Structure Diagram. UML 1.x only had composition to model internal structure, UML2.0
    • introduces this d. to model “hidden”detail
    • UML põhidiagrammid
    • Use Case
    • sequence diagram
    • collaboration diagram
    • state diagram
    • activity diagram
    • component diagram
    • deployment diagram
    • Object Orientation
    • Polymorphism
    • WATERFALL MODEL
    • CAPABILITY MATURITY MODEL (CMM)
    • Capability Maturity Model
    • Tarkvaraprotsessi võimekus
    • Tarkvaraprotsessi tulemuslikkus
    • Tarkvaraprotsessi küpsus
    • tase
    • tase
    • määratletud
    • tase
    • tase
    • research and development
    • The OPEN Process
    • OPEN consortium
    • The OPEN Process serious drawback
    • Object Modeling Language
    • RUP—
    • Fine scale feedback
    • Continuous process
    • Shared understanding
    • Programmer welfare
    • Extreme Programming - Four Variables
    • communicating
    • simplest
    • feedback
    • courage
    • Extreme Programming - Estimating User Stories
    • Usage
    • Benifits
    • Limitations
    • Feature-Driven Development (FDD)
    • FDD Best Practices
    • Short Comparison FDD vs XP
    • collective code ownership
    • individual code
    • ownership
    • Scrum
    • is a project management method
    • Scrum of Scrums
    • product backlog
    • sprints
    • scrum
    • sprint planning session
    • sprint retrospective
    • ScrumMaster
    • RUP: DYNAMIC AND STATIC
    • 23. THE DYNAMIC STRUCTURE OF THE RATIONAL UNIFIED PROCESS
    • начало
    • требования
    • разработка
    • Phase
    • Enterprise Unified Process
    • Enterprise Unified Process
    • Phases
    • Disciplines
    • Best Practices of EUP
    • Open Unified Process (OpenUP)
    • CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
    • 30. CMMI Representations
    • Capability Profile
    • Crystal Clear
    • 43
    • Goal Development in SW Development process. Delivery Process in SW Development process
    • Agile SW Delivery
    • AGILE METHODOLOGIES(A.M.)
    • Agile alliance
    • A.M
    • Major A.M
    • XP values
    • Software Quality
    • quality of
    • quality of conformance
    • quality of design
    • Definition
    • internal
    • external quality characteristics
    • Quality Software Management: Systems Thinking
    • Source code quality
    • Software Quality Factors
    • Understandability
    • completeness
    • conciseness
    • portability
    • consistency
    • maintainability
    • testability
    • usability
    • reliability
    • Structuredness
    • efficiency
    • security
    • Acceptance Testing
    • acceptance testing
    • field (acceptance) testing
    • Configuration Management
    • CM standarts
    • Configuration management planning
    • CM planning
    • Formal documents)
    • CM plan
    • C.item identification
    • Doc naming scheme
    • hierarchical scheme
    • The C. database
    • Change management
    • Change request form
    • Change tracking tools
    • Change control board
    • Release management
    • System releases
    • Release problems
    • Release creation
    • System Building
    • CASE tools for configuration management
    • Manage Change Requests
    • Tool Support
    • Rational ClearCase
    • Rational ClearQuest

    Kommentaarid (0)

    Kommentaarid sellele materjalile puuduvad. Ole esimene ja kommenteeri


    Sarnased materjalid

    548
    pdf
    Cialdini raamat
    378
    pdf
    A New Earth
    555
    doc
    Programmeerimiskeel
    102
    pdf
    Kommunikatsioonimudel
    946
    pdf
    TheCodeBreakers
    574
    pdf
    The 4-Hour Body - An Uncommon Guide to Rapid Fat-Loss-Incredible Sex-and Becoming Superhuman - Timothy Ferriss
    1168
    pdf
    Liha töötlemine
    904
    pdf
    Christopher Vogler The Writers Journey





    Faili allalaadimiseks, pead sisse logima
    Kasutajanimi / Email
    Parool

    Unustasid parooli?

    Pole kasutajat?

    Tee tasuta konto

    UUTELE LIITUJATELE KONTO MOBIILIGA AKTIVEERIMISEL +50 PUNKTI !