Stereotypes & Framework in conceptual architecture Lecture 13-15 1.

Slides:



Advertisements
Similar presentations
Writing Good Use Cases - Instructor Notes
Advertisements

Entity Relationship (E-R) Modeling
Managing Hardware and Software Assets
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 1: The Database Environment
Requirements Engineering Process
Improving Human-Semantic Web Interaction: The Rhizomer Experience Roberto García and Rosa Gil GRIHO - Human Computer Interaction Research Group Universitat.
Service Oriented Architecture Reference Model
ASYCUDA Overview … a summary of the objectives of ASYCUDA implementation projects and features of the software for the Customs computer system.
Relational Database and Data Modeling
1 Aspects of IEEE P1471 Viewpoints in Unified Modeling Language (UML) Manzur Ashraf, BRAC University Humayra Binte Ali, Dhaka University Md.Mahfuz Ashraf,
18 Copyright © 2005, Oracle. All rights reserved. Distributing Modular Applications: Introduction to Web Services.
Data Architecture at CIA Dave Roberts Chief Technical Officer Application Services, CIO CIA
Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
Presented to: By: Date: Federal Aviation Administration Registry/Repository in a SOA Environment SOA Brown Bag #5 SWIM Team March 9, 2011.
Language Specification using Metamodelling Joachim Fischer Humboldt University Berlin LAB Workshop Geneva
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
MULTIPLYING MONOMIALS TIMES POLYNOMIALS (DISTRIBUTIVE PROPERTY)
SUBTRACTING INTEGERS 1. CHANGE THE SUBTRACTION SIGN TO ADDITION
Addition Facts
The ANSI/SPARC Architecture of a Database Environment
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design 1.
Chapter 7 – Design and Implementation
Week 2 The Object-Oriented Approach to Requirements
Configuration management
Software change management
1 Dr. Ashraf El-Farghly SECC. 2 Level 3 focus on the organization - Best practices are gathered across the organization. - Processes are tailored depending.
Chapter 5 – Enterprise Analysis
Conceptual Architecture
Table 22.1 Stakeholder summary for the Odd Shoe Company
Object-Oriented Software Engineering Visual OO Analysis and Design
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
1 Quality of Service Issues Network design and security Lecture 12.
© 2011 TIBCO Software Inc. All Rights Reserved. Confidential and Proprietary. Towards a Model-Based Characterization of Data and Services Integration Paul.
Fifth Edition 1 M a n a g e m e n t I n f o r m a t i o n S y s t e m s M a n a g I n g I n f o r m a t i o n T e c h n o l o g y i n t h e E – B u s i.
1 UML ++ Mohamed T IBRAHIM University of Greenwich -UK.
the Entity-Relationship (ER) Model
Database System Concepts and Architecture
Lecture 6: Software Design (Part I)
Lecture 5: Requirements Engineering
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Executional Architecture
Implementation Architecture
Addition 1’s to 20.
Requirements Analysis 1. 1 Introduction b501.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Introduction.
25 seconds left…...
XP New Perspectives on Browser and Basics Tutorial 1 1 Browser and Basics Tutorial 1.
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Analysis of Software Architectures.
© Paradigm Publishing Inc Chapter 10 Information Systems.
Week 1.
Systems Analysis and Design in a Changing World, Fifth Edition
Database Administration
Distributed DBMS©M. T. Özsu & P. Valduriez Ch.15/1 Outline Introduction Background Distributed Database Design Database Integration Semantic Data Control.
Chapter 11 Component-Level Design
From Model-based to Model-driven Design of User Interfaces.
THE OBJECT-ORIENTED DESIGN WORKFLOW Interfaces & Subsystems.
The Architecture Design Process
Software Architecture in Practice (3rd Ed) Introduction
Chapter 10 Architectural Design
The Design Discipline.
What is Enterprise Architecture?
BTS430 Systems Analysis and Design using UML Domain Model Part 1—Finding Conceptual Classes.
Software Architecture in Practice Architectural description (The reduced version)
Systems Analysis and Design in a Changing World, 3rd Edition
Actors and Use Case Diagrams Month Day, Year. Agenda Training Plan Overview Review Detailing Requirements with Requisite Pro Concepts Setting Up XDE Integration.
UML - Development Process 1 Software Development Process Using UML.
CS223: Software Engineering Lecture 13: Software Architecture.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
Design Yaodong Bi.
Presentation transcript:

Stereotypes & Framework in conceptual architecture Lecture

The first alternative 2 1. Underline the key concepts in the requirements, (ask yourself does this concept relates to the functionality?) 2. Copy key concepts onto a sheet of paper, (consider each one to see if it is a viable component) 3. Draw the components and add connectors, (add arrows and labels)

Obtain a system narrative Custom Shooz plan to advertise using conventional means, but want the website to be a location where customers can find out about their custom range, get the measurement kit, and customize and order shoes. They also want the site to interface to their accounting system. The President of Custom Shooz, Funk O. Sole, explains: “So, what we did was develop a little measurement kit that we send out to folks and they have to send it back. We've improved it over the last couple of years so that it's almost foolproof. Once we have the customer's measurement kit in, we can produce almost any shoe from our range - all the custom stuff, like stitched-on patterns, dye colours and finishes, laces and buckles, can be done without them ever being within a thousand miles of our store!” 3

Identify key concepts Custom Shooz plan to advertise using conventional means, but want the website to be a location where customers can find out about their custom range, get the measurement kit, and customize and order shoes. They also want the site to interface to their accounting system. The President of Custom Shooz, Funk O. Sole, explains: “So, what we did was develop a little measurement kit that we send out to folks and they have to send it back. We've improved it over the last couple of years so that it's almost foolproof. Once we have the customer's measurement kit in, we can produce almost any shoe from our range - all the custom stuff, like stitched-on patterns, dye colours and finishes, laces and buckles, can be done without them ever being within a thousand miles of our store!” 4

Draw and connect HTTP Acct I/F Order shoe Public page Personal page Customer acct Product range Customise shoe Templates Shoe production Customer measurements 5

The second alternative  Assign every possible concept from the requirements to a category:  Data:  Data: information that is stored, processed, etc. Not directly a component but you might need components for data management  Function:  Function: Something done by something - typically components  Stakeholder:  Stakeholder: users, organizations - never components 6

The second alternative  Assign every possible concept in a system narrative to a category:  System:  System: external systems - sometimes you need an interface component  Hardware:  Hardware: physical components  Abstract concept:  Abstract concept: explanation of something - hardly ever components 7

Refine to components Advertise - abstract concept  X Website - abstract concept  implementation Customers - stakeholder  Customer account + Personalised page Custom range - Data  Product range Measurement kit - Data  Customer measurements Customise shoe - Function Order shoe - Function Accounting I/F - external system  Acct I/F Produce shoe - function/external system  Shoe production Patterns and finishes - part of Customise shoe 8

Refine the architecture  Add or split components  Clarify responsibilities  Identify stereotypes  Create data models  Explore behaviour A component is a set of related responsibilities. So, split a component if responsibilities are not related … Replication can be considered at this stage, to account for performance and availability needs 9

A stereotype indicates that a component (or in UML, a class) has certain properties or attributes. Conceptual stereotypes Does a component have special types of responsibilities? User presentation Persistent storage Real-time response 10

Component stereotypes 11  Adding semantics to components through stereotypes  Tagging components to indicate certain properties  Presentation component  Presentation component: interactions with users  Persistent storage  Persistent storage: persistent/permanent data or data from external systems  Real-time components  Real-time components: components that handle requests quickly

Custom Shooz architecture with stereotypes Public Page Personal Page Customer accounts Customer meas. Product range Order shoesCustomise shoes Shoe production Browse products Templates Acct I/F HTTP 12

Data models  A data model captures the essential structure of data:  Data along connectors  Persistent data Student ID : integer Subject ID : integer points : integer Major name : String enrolled-in currently-taking 0..* 13

What is behaviour A system has function, structure and behaviour Behaviour is the set of actions that the system performs Behaviour can be explored through: Use Case maps Sequence diagrams 14

Extract events from narratives tracking data sort the data export Julie is interested in correlating sightings in the Northern beaches area of Sydney with bushfire patterns. She brings up tracking data for the last five years and proceeds to sort the data, and then export it into a form that it can be used by a statistical analysis package Request Historical Tracking Data Sort Historical Tracking Data Export Historical Tracking Data 15

Events trigger use-case maps  Use-case maps allow us to visualise a path of action through a system  A trace shows the sequence of activities  Activity is triggered by an event  Each time the trace crosses a component, it exercises a responsibility CompB Data Comp A Comp C Resp C1 EventName RespB3 Resp A2 Use-case maps facilitate understanding of macroscopic behaviour 16

Conceptual Architecture Framework 17

 Business architecture layer: business activitiesobjectives  The business architecture layer contains an overview of all business activities, their objectives including the relations between each other from a business point of view. rolesorganizational units  It defines the necessary roles and organizational units that are involved in these activities. strategic decisions  The business architecture has to ensure that process- related to strategic decisions are based on current visions and business objectives. 18 Conceptual Architecture Framework

19  Application architecture layer:  The application architecture consists of “a set of applications and their interactions” assigned  The different business processes are assigned to several functions provided by the applications. understanding  The main focus of the application architecture lies on understanding all the functions and their interrelations that help to construct and maintain the architecture. business constraints technical constraints  Beside any business constraints (like defined roles or locations) also technical constraints like standards and trends (XML, Web Services) should be considered.

 Data architecture layer:  It defines: “what data is needed to meet user needs and how this data is conceptually structured” source systems  It examines the completeness and correctness of source systems that are needed to obtain data and identifies the data facts and dimensions. data models  It also defines data models, and helps to establishes a set up for metadata infrastructure. standards  The data architecture defines the applicable standards concerning the data management, distribution and access. 20 Conceptual Architecture Framework

 Technical architecture layer: required infrastructure  Here, focus is on the description of required infrastructure elements like hardware and software and their relationships, as well as possibilities for consistency and sharing between different systems. technologies  Moreover, the technical architecture defines technologies that support applications and data management, services and protocols, as well as development methods and tools. 21 Conceptual Architecture Framework

 Evolution aspects  System technical aspects  Quality surveillance & assurance  Capacity planning  User support  Protection & security management  Evolution control  Strategy & platform 22