Comunidad IT English Class N 3

Name:

Markup Language
A markup language is a modern system for annotating a document in a way that is syntactically distinguishable from the text. The idea and terminology evolved from the "marking up" of manuscripts, i.e., the revision instructions by editors, traditionally written with a blue pencil on authors' manuscripts. Examples are typesetting instructions such as those found in troff and LaTeX, or structural markers such as XML tags. Markup is typically omitted from the version of the text that is displayed for end-user consumption. Some markup languages, such as HTML, have presentation semantics, meaning that their specification prescribes how the structured data are to be presented, but other markup languages, like XML, have no predefined semantics. A well-known example of a markup language in widespread use today is HyperText Markup Language (HTML), one of the document formats of the World Wide Web. HTML, which is an instance of SGML (though, strictly, it does not comply with all the rules of SGML), follows many of the markup conventions used in the publishing industry in the communication of printed work between authors, editors, and printers. There are three general categories of electronic markup: Presentational markup The kind of markup used by traditional word-processing systems: binary codes embedded in document text that produce the WYSIWYG effect. Such markup is usually designed to be hidden from human users, even those who are authors or editors. Procedural markup Markup is embedded in text and provides instructions for programs that are to process the text. Well-known examples include troff, LaTeX, and PostScript. It is expected that the processor will run through the text from beginning to end, following the instructions as encountered. Text with such markup is often edited with the markup visible and directly manipulated by the author. Popular procedural-markup systems usually include programming constructs, so macros or subroutines can be defined and invoked by name. Descriptive markup

Markup is used to label parts of the document rather than to provide specific instructions as to how they should be processed. The objective is to decouple the inherent structure of the document from any particular treatment or rendition of it. Such markup is often described as "semantic". An example of descriptive markup would be HTML's tag, which is used to label a citation. There is considerable blurring of the lines between the types of markup. In modern word-processing systems, presentational markup is often saved in descriptive-markup-oriented systems such as XML, and then processed procedurally by implementations. The programming constructs in descriptivemarkup systems such as TeX may be used to create higher-level markup systems which are more descriptive, such as LaTeX. In recent years, a number of small and largely unstandardized markup languages have been developed to allow authors to create formatted text via web browsers, for use in wikis and web forums. These are sometimes called lightweight markup languages. The markup language used by Wikipedia is one example.

MVC Pattern
In software engineering, ModelViewController (MVC) is an architectural pattern that splits interactions between users and applications into three roles: the Model (business logic), the View (user interface), and the Controller (user input). This separation of concerns facilitates the independent development, testing, and maintenance of each role. Although MVC comes in different flavors, the control flow is generally as follows: 1. The user interacts with the user interface in some way (for example, by pressing a mouse button). 2. The controller handles the input event from the user interface, often via a registered handler or callback, and converts the event into an appropriate user action, understandable for the model. 3. The controller notifies the model of the user action, possibly resulting in a change in the model's state. (For example, the controller updates the user's shopping cart).[7] 4. A view queries the model to generate an appropriate user interface (for example the view lists the shopping cart's contents). The view gets its own data from the model. In some implementations, the controller may issue a general instruction to the view to render itself. In others, the view is automatically notified by the model of changes in state (observer) that require a screen update.

5. The user interface waits for further user interactions, which restarts the control flow cycle. Some implementations (e.g., W3C XForms) also use the concept of a dependency graph to automate the updating of views when data in the model changes. The goal of MVC is to simplify the architecture by decoupling models and views, and to make source code more flexible and maintainable. MVC has also been used to simplify the design of autonomic and self-managed systems. The Model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react. The View renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A view port typically has a one to one correspondence with a display surface and knows how to render to it. The Controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and a view port to perform actions based on that input. An application based on the MVC pattern may be a collection of modelview controller triads, each responsible for a different user interface element. The Swing GUI system, for example, models almost all interface components as individual MVC systems. MVC is often seen in web applications where the view is the HTML or XHTML generated by the application. The controller receives GET or POST input and decides what to do with it, handing over to domain objects (i.e. the model) that contain the business rules and know how to carry out specific tasks such as processing a new subscription, and which hand control to (X)HTML-generating components such as templating engines, XML pipelines, Ajax callbacks, etc. The model is not necessarily a database. In MVC, the Model is both the data and the business logic needed to manipulate the data in the application. Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple applications that have little domain logic there is no real distinction to be made. Active record is an accepted design

pattern that merges domain logic and data access code; a model which knows how to persist itself.

Service-Oriented Architecture (SOA)

In software engineering, a Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components(discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration. SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them. XML is often used for interfacing with SOA services, though this is not required. JSON is also becoming increasingly common. SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation. Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services. SOA can be seen in a continuum, from older concepts of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA). Services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.

SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the nth application is low, as all of the software required already exists to satisfy the requirements of other applications.

Scrum
Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. Scrum contains sets of methods and predefined roles. The main roles in Scrum are: 1. the "ScrumMaster", who ensures the process is followed, removes impediments, and protects the Development Team from disruption 2. the "Product Owner", who represents the stakeholders and the business 3. the "Development Team", a cross-functional, self-organizing team who do the actual analysis, design, implementation, testing, etc. A sprint is the basic unit of development in Scrum. Sprints last between one week and one month, and are a "timeboxed" (i.e. restricted to a specific duration) effort of a constant length. Each sprint is preceded by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and followed by a review or retrospective meeting, where the progress is reviewed and lessons for the next sprint are identified. The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format (See terminology below). The product backlog is the What that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team. The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog

items. For example, if the add spellcheck and add table support features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher. The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. During each sprint, the team creates finished portions of a product. The set of features that go into a sprint come from the product backlog, which is a prioritized list of requirements. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he or she wants completed (the ones with the highest priority). The team then determines how much of this they can commit to complete during the next sprint, and records this in the sprint backlog. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. Development is timeboxed such that the sprint must end on time; if requirements are not completed for any reason they are left out and returned to the product backlog. After a sprint is completed, the team demonstrates how to use the software.

Questions:
1. What is a Markup Language 2. Give 4 examples of markup languages (you can search on the web) 3. Enumerate the three types of markup languages and describe them in two lines 4. Give 4 examples of markup languages usage (you can search on the web) 5. Whats the MVC Pattern? 6. Enumerate the parts of the MVC pattern 7. Explain the function of the controllers in two lines 8. In what kind of applications do we mostly use MVC pattern? 9. Whats the model and what does it includes? 10.What is SOA? 11.Which ones are the most often languages used for interfacing with SOA services? Are these the only ones?

12.In what kind of environment is SOA used? 13.In what kind of terms does SOA defines the interface of web services? 14.Why do the developers make services accessible over a network? 15.Whats the aim of SOA? 16.Whats SCRUM development? 17.Enumerate Scrums main roles and explain them 18.What is a sprint and how long it lasts? 19.Whats the Product Backlog and based on what is it ordered? 20.What are the deliverables of each sprint?